Public GETs, In Concert With Private POST, PUT, And DELETE For Your APIs
Opening your site and your data through an API can be an uncomfortable experience. Simple rules for structuring and securing your API mean it doesn't have to be.
Join the DZone community and get the full member experience.Join For Free
Another story I wanted to tell from my work to expose an API yesterday, so I could get help with it, was focused around the service composition that I used. I feel like this is a powerful story, that should be told, and retold among API evangelists, across conversations with folks who are new to the API space, and to the concept of putting APIs to work in their daily business worlds.
The largest concern I hear from people who don't fully understand APIs is the perceived loss of control from putting things up on the open Internet. When you don't understand modern API management infrastructure, and the nuance of API service composition, what an API does can seem pretty scary. The first lesson around me exposing of an API, from the @APIStrat speaker database, was about soliciting help from Nicolas Grenié (@picsoung), and the second lesson is centered around how I used a combination of public / private endpoints to make this work.
The first two endpoints or methods I published from my speaker databases, were simple GETs:
All 351 speakers in our database are already public, on the schedules for each of the six @APIStrat events, so there really is no reason why I would lock up the APIs to get this information--I am just returning JSON representations, in addition to the HTML I already do on the websites.
However, for the collaboration part with @picsoung the POST, PUT, DELETE (aka Add, Update, Delete), I'm going to need to secure things a little more. Using my already in place, 3Scale API management infrastructure, I have an access tier specifically for my partners like 3Scale, WSO2, and @picsoung already has a set of API keys at this API plan level. I simply put the three endpoints / methods for POST, PUT, and DELETE for the URLs above, into my "partner" level, and they require an appID and appKey for each API call--secured.
This is a simple, yet powerful example of how APIs work, and specifically the level of control that API service composition gives you. I can easily make the speakers across our six conferences available in a machine readable format for use in other websites, and mobile applications. With the same API, I am also able to open up write capabilities to the partners who I trust, enabling them to help me evolve my speakers information. I am able to publicly share my resources via an API, making HTML and JSON versions of it available, while also opening up important collaboration which will move my work forward, in a safe, and secure way.
This is APIs in action, and how they actually give you more control over the digital resources that are fueling your daily operations.
Published at DZone with permission of Kin Lane, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.