Geeks will be geeks. We can’t resist buying the new gadget to play with, especially if it’s hackable. Recently our CEO, Steve, could not resist buying an Amazon Echo, which turned into the beginning of an API journey at APIStrat Austin. When the Amazon Echo was launched in November 2014, I don’t remember people getting overexcited about it. I don’t remember people screaming on social networks that they were dying to get one. Even if it was way cheaper than what it is now, I don’t think people understood at that time the real value of this device. Now, it looks like it was the must-have thing under your tree for Christmas this year. I want to share my story of playing with the Echo for a few days and see how this device will influence the API space in the coming years.
The first time I played with it was at re:Invent in Las Vegas. At the Amazon stand they had a giant Echo replica that you cou…
Yesterday we were invited to present at the API Management meetup in San Francisco (see the group info here -> well worth signing up!) and tackled the topic of how APIs are changing the way software is built.
Here are the slides from the talk:
Enjoyed meeting everybody there – thank you to the organizers …
- The App developer (consumer of the API) gets its client_id and client_secret via the buyer portal (in case of oAuth v1 would be consumer_key, etc.). These keys get provisioned after the account is validated, or by the provider through their portal, or via the Account API (e.g. Legacy systems or buyer portals not based on 3scale’s).
- The App developer does the requests to the API as per standard oAuth, any library is supported since he knows its client_id and client_secret. Regardless if it’s a call to the API or or the GetAccessToken the client_id is always sent to the API provider (even once the access_token has been granted). The request is signed with his client_secret.
The API provider calls 3scale’s backend with the client_id from the requ…