Download - APIs : Mapping the way
Mapping the Way
• Looking back – where have we come from • Current state of the world • Taking a look to the future
APIs • An API is a business capability delivered over the Internet
to internal or external consumers – Network accessible funcLon – Available using standard web protocols – With well-‐defined interfaces – Designed for access by third-‐parLes
• A Managed API is: – AcLvely adverLsed and subscribe-‐able – Available with SLAs – Secured, authenLcated, authorized and protected – Monitored and moneLzed with analyLcs
Web API History
• The earliest APIs were various XML and SOAP services – Also people manipulaLng web applicaLons and parsing HTML
Authorize.net (1998)
Salesforce
Dec 6th 2000
Key differenLators in the evoluLon
• Self-‐signup / Portal / API Store • A clear moneLzaLon model – And a clear value model
• Ecosystem thinking – Hackathons – Forums* – Social Media integraLon
• Monitoring • Simple keys to OAuth to OAuth2
* yes, I know the proper LaLn is fora. I’m not an ancient Roman though
REST or rest?
• REST – RepresentaLonal State Transfer – From Roy Fielding’s thesis (hbp://freo.me/O9t4nj)
• A clear shie from SOAP/HTTP to more resful JSON/HTTP
• REST is a good thing – but actually quite rare amongst many APIs
PrioriLzing which bits of REST
• Proper use of verbs • Caching and cache-‐ability • Good error codes • Do not use poorly defined aspects of the HTTP spec – E.g. including an EnLty Body with a DELETE
• Re-‐usable / bookmark-‐able links and URIs • HATEAOS
Versioning
Versioning
• There are some who say that APIs should NEVER have a version number in the URI
• I disagree: – Versioning properly allows for evoluLon and agility
– Clear deprecaLon and well-‐defined support for old versions
hbp://www.pdt.com/news/688
Minimum Viable API
• Minimum Viable Product has just enough features that the product can be deployed and used by some customers, and no more. – Typically this is a small subset of the future customer base
• “Minimum Viable API” is just enough API that it can be used by some partners
• Highly recommended especially in evolving an API strategy
API First
• Start with the API – Before the website / mobile app / internal app / …
• Why? – Ensures a good API – External Developers are not second class ciLzens – Inherently “mobile-‐first-‐friendly” – Decoupled development – Evolve-‐ability – APIs everywhere
API First has requirements
• Excellent access control • Versioning and agile • Throbling • Metering and moneLzaLon
OAuth2
• OAuth2 has widely taken over from simple API keys – E.g. Google, Github, Twiber, etc
• Standard model from the IETF • Almost the same as a simple key – Well-‐defined place to put into headers – Refresh semanLcs – If you offer a long-‐lived key then ignore refresh
OpenId Connect
What is OpenID Connect
• A well-‐defined pabern for using OAuth2 for idenLty – A pre-‐defined scope – A well-‐defined REST API for user info – A discovery model
• My predicLon: – Widespread adopLon
hbps://www.flickr.com/photos/1stpix_diecast_dioramas/
Ecosystems • Allow smaller organizaLons to compete effecLvely – Be more agile, nimble
• Allow larger organizaLons to compete more effecLvely – By working with smaller, more agile partners!
• Enable “best-‐of-‐breed” capabiliLes to conjoin to create beber soluLons
• Take advantage of APIs and promote APIs – A virtuous circle
The wider sense of virtualizaLon
Import org.apache.x
} Automation Control Monitoring Agility Flexibility
APIs and PaaS
• APIs are the virtualizaLon of funcLon • PaaS is the virtualizaLon of applicaLon deployment
• App Factory is the virtualizaLon of development
• Together this is basis for the virtualizaLon of an ecosystem
Summary
• Build an API strategy that revolves around: – CreaLng or parLcipaLng in an ecosystem – Giving API consumers the tools and capabiliLes they need
– By being agile and responsive – And using the right technologies
QuesLons?
hbp://wso2.com/contact