API Server Client Setup

Question

Suppose you have a setup where there is an API Server and all interaction revolve around the API. There is the admin, public and third party components that interact with the API server.

Suppose we have an e-commerce model, the components' have the following capabilities: Admin - ability to manage products, orders and customer information Public - ability to manage customer and order information belonging to the user Third Party - ability to retrieve list of products, view orders - create orders in behalf of the user (meaning must have authorization from user) - view customer info (need authorization from user)

My concern is regarding authorization. I'm familiar how to handle the third party through the OAuth workflow. But I'm confused with the Admin and Public components. The said two components doesn't seem to fit the OAuth workflow were there are typically 3 actors: the server, consumer and user.

For example for the public component, it's the front facing application where your users can manage their profiles, order and view products. Are we going to treat this component as special from the API authorization perspective. The same goes with the admin component which offers the ability to manage almost all aspect of your application, even set API keys.

Just like Facebook, Twitter, etc.. They offer an API. But internally do they communicate using some sort of API as well?

Should these core components (UI for admin and public) NOT be decoupled from the API Server in the first place?

Answer 1

The OAuth 2.0 authorization framework enables a third-party application to obtain limited access to an HTTP service, either on behalf of a resource owner by orchestrating an approval interaction between the resource owner and the HTTP service, or by allowing the third-party application to obtain access on its own behalf. This specification replaces and obsoletes the OAuth 1.0 protocol described in RFC 5849.

Thats the abstract to RFC 6749.

So the simple answer is that's what it's for. The less facetious answer is stop thinking in terms of multiple interactions all at once. Despite all the object facade all code is sequential.

Treat this as a cascade of interactions; where your library acts as intermediary between 2 sides. It's harder to be more specific without details of your app.

What I would do is the old unix philosophy: build a test program that takes one object call from 3rd party, stores it somehow and passes it to secondary thread/ object etc. And then that thing interacts with HTTP service. Then revisit design

Why old timers recommend this way is it may not do much, but it illuminates your understanding of the problem far deeper than use cases. Also, now you can tell your boss you're 50% complete with about 70% to go.