Introduction

I will admit, there is a learning curve when working with WAK: Core and WAK: OAuth. When designing the WAK assets we had to find a balance between usability, performance, and the wild-wild-west of Web APIs in general. The problem is there are many ways to implement RESTful interfaces and even though there is an RFC for OAuth, everyone likes to interpret it differently so naturally implementations will vary slightly. The common denominator for the Web API mess is the HTTP protocol.

WAK: Core gives you the framework to create representations of each API endpoint and works with multiple Unity HTTP providers. What is left up to you is a repeatable workflow of identifying the API URI and modeling request and response payloads with C# classes. At this point, interfacing with third party APIs turns into a simple call to the Send method on the classes you created. Then you encounter another problem… authentication and authorization!

WAK: OAuth allows you to interface with APIs that are protected by the OAuth security mechanism. Once you have modeled the API endpoints your application wants to interface with, the next step is mostly a configuration step based on the API provider’s documentation. WAK: OAuth handles the most common OAuth workflow: the Authorization Code and Access Token exchange. The asset is extensible beyond this workflow, but I have not yet encountered an API where this was necessary.

I encourage you to read all of documentation and become comfortable with creating HttpOperation abstractions into your favorite API before continuing.

Recently a customer wanted to interface with various Google services and LinkedIn APIs. First off, Google is a monster, so you need to figure out which APIs you need. WAK: OAuth comes with a tool that links to documentation, permission scopes, and discovery documents for all that Google has to offer. These links will be instrumental in creating your HttpOperations and properly configuring the OAuth Interceptor. Next up, LinkedIn. They like to do things their own way and I’ve always had some issue or another interfacing with their API. You can watch a couple of LinkedIn attempts here and here. These quick videos give you insight what it’s like troubleshooting connectivity to APIs that need a little extra help.

Of course, in the end, we got it all wired up and working, but it is tough for many Unity developers to step out of the familiar Unity workflow and get bogged down with HTTP and APIs and crap they don’t know and really don’t care to know. Supporting WAK assets has been fun. Because interfacing with APIs where you have no control over can be a black art, we take the time to educate. We get to help our customers with tough problems and get the opportunity to see how our assets are being used in a larger ecosystem which helps us improve our products.