Following real-time API design
Following real-time API design
Join the DZone community and get the full member experience.Join For Free
SnapLogic is the leading self-service enterprise-grade integration platform. Download the 2018 GartnerMagic Quadrant for Enterprise iPaaS or play around on the platform, risk free, for 30 days.
What Steve Chambers has done is to list out the options for API authentication and settled on (my emphasis added) Token Keys with Request Signing.
AuthenticationWhen I saw this I thought "Yes!". That's because I remember a similar exercise two years ago which also ended in Token Keys (called API Keys in that case) being selected. In that case also, a facade pattern (using a Gateway) was employed in order to separate the API delivery and definition from the back-end infrastructure. It's interesting that in that case we also allowed SSL with HTTP Digest Auth for (as Steve calls them) "pesky humans with a browser" but the Gateway takes note of how the authentication is performed and that is taken into account in policies (the "authentication context").
- HTTP Basic Authentication is ruled out (why: SSL, Logout, Client retains auth info)
- HTTP Digest Authentication is ruled out (why: SSL)
- Public Key Authentication is ruled out (why: complexity)
- Credentials in Request is ruled out (why: creeds should not be passed in each Request)
- Token Keys with Request Signing (of all headers and payload for zero collisions) are selected.
The other aspect I enjoyed reading about is the REST design constraint. Steve writes:
This API is resource-based, not service-based, as per the REST design constraint.Again I thought "Yes!" because this goes back to one of my original bugbears about (firstly) heavyweight Web Services and (now) APIs. Back in the world of Web Services, initially it was seen as part of Distributed Computing and it was all about RPC. Then, Document-Literal SOAP was rightly seen as the best option, and we moved to to that model. That was a good thing. It made overlaying REST on SOAP a bit easier.
- You can access the team artefacts like people bios and written papers.
- You cannot execute the “give_the_gal_a_raise()” method on a staff object
Even further back, at the risk of seeming like an old codger, this always reminds me of my early days working as a programmer for an EDI VAN in Dublin moving EDI processes to the new-fangled Internet. EDI was (and is) all about moving documents (resources) around, and updating the status of those resources (purchase orders are approved, etc). At the time in Dublin, it seemed like every other programmer was working in distributed computing (CORBA) at Iona (which I initially encountered as a campus company). That is a different world. It's the difference between doing a POST (aargh) on a method called "approve_purchase_order()" and using PUT to update the status of the purchase order resource. Much of REST is centered on the old ideas which worked, and still work, for EDI. There, I sound like an old codger now.
I'll be following Steve's notes with interest...
Published at DZone with permission of Mark O'Neill , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.