APIStrat 2017: API Design in the Age of Bots, IoT, and Voice
•
5 gostaram•1,695 visualizações
Our API design should be user-first: a reflection of the kinds of capabilities and outcomes our users expect. New devices and software interaction will change the way we design web APIs. Presented at APIStrat 2017
Recomendados
Recomendados
Mais conteúdo relacionado
Mais procurados
Mais procurados (20)
Semelhante a APIStrat 2017: API Design in the Age of Bots, IoT, and Voice
Semelhante a APIStrat 2017: API Design in the Age of Bots, IoT, and Voice (20)
Mais de LaunchAny
Mais de LaunchAny (19)
Último
Último (20)
APIStrat 2017: API Design in the Age of Bots, IoT, and Voice
- 1. API Design in the Age of Bots, IoT, and Voice James Higginbotham @launchany https://apideveloperweekly.com
- 2. The Road So Far… 1990s Distributed Object Integration 2000s Corp-to-Corp Integration 2010s + Mobile/Data Integration
- 3. The State of API Design in 2017
- 4. APIs are stuck in the land of CRUD
- 5. API Conversations with CRUD
- 6. API Design is an architectural concern that combines business, product design, and technology
- 8. When APIs Meet Jobs-To-Be-Done
- 9. 1. Hypermedia and HATEOAS (again)
- 10. Choose Your Own Adventure for APIs
- 11. When APIs Meet Jobs-To-Be-Done { … "_links": { “self": {"href": "/approval-requests/d796f2d0eb72492bb088"}, “approve": {"href": "/approval-requests/d796f2d0eb72492bb088/approve"}, “decline": {"href": "/approval-requests/d796f2d0eb72492bb088/decline"}, }, … }
- 15. 1_Blank
- 16. IoT
- 18. 3. User-First, Capability-Driven API Design
- 19. Visual Voice
- 20. GET https://api.myexample.com/projects Accept: application/json;q=0.5,text/html;q=1.0 4. Content Negotiation For Visualization HTTP/1.0 200 OK Date: Tue, 16 June 2015 06:57:43 GMT Content-Type: text/html <html>…</html>
- 21. Sessions and Context-Based Interaction
- 22. 5. Front-End APIs for Context Map APIs to devices and manages interactive sessions Ask for additional details before calling backend APIs Adaptive to support optional context data (min, typical, max data input) { … "_links": { “self": {"href": "/sessions/d796f2d0eb72492"}, “accounts": {"href": "/ sessions/d796f2d0eb72492/accounts"}, “credit-lines": {"href": "/approval-requests/d796f2d0eb72492/credit-lines"}, }, … }
- 24. Edge Computing with NAS
- 25. AWS Snowball Edge + AWS Greengrass
- 26. 6. On-Device APIs One interface, multiple implementations Store-and-forward strategy with synchronization when offline Local API gateway and management Monitoring and managing edge nodes goes beyond the data center
- 27. Bots
- 29. 7. Bots as Next Generation APIs Currently, the assumption is that bots are talking to humans But, what if our apps could talk to bots as if it were an API? What if natural language is better for some APIs? What if a hybrid language is necessary to support next gen API integration?
- 30. API Design Is Changing 1. Hypermedia and HATEOAS 2. Event subscriptions 3. Capability-driven API design 4. Content negotiation 5. Front-end context APIs 6. On-device APIs 7. Bots as next generation APIs
- 31. The Road Ahead 1990s Distributed Object Integration 2000s Corp-to-Corp Integration 2010s + Mobile/Data Integration 2020s ? Capability Integration
Notas do Editor
- Training/coaching API strategy
- CORBA – distributed components for system interoperability needs SOAP – distributed computing over HTTP driven by integration needs JSON + HTTP – distributed computing for billions of devices
- Many people consider REST dead, or at least boring…I don’t REST w/ Hypermedia, GraphQL, and GRPC are emerging as next generation There WILL BE ANOTHER GENERATION. WHAT WILL BE THE DRIVER(S)?
- As I train organizations, I see the same common problem: we are stuck in CRUD. I’m as guilty also. Industry trends are going to FORCE us to revisit our API design assumptions If we can build CRUD APIs in 15 minutes, we have to ask ourselves if we value our API consumers. They don’t want to manage a database over HTTP.
- Typical CRUD conversation – often focused on a database with row-by-row access
- As a result, we must consider the end-user goals and user experience (UX) as part of our API design process. Let’s look at some emerging trends in UX that will INFLUENCE OUR API DESIGN in the coming months and years ahead
- Some are saying that these communication platforms are starting to REPLACE many of the collaborations currently occurring over EMAIL that ASK TO OPEN AN APP RESULT: We are now seeing the early stages of a TRANSITION from USERS going to the APPLICATION, TO APPLICATIONS going to the user
- Amber mentioned what is so true: we expect APIs to “just work” when we need them More than exposing data ROW-by-ROW It is about having a DYNAMIC CONVERSATION
- Hypermedia extends the conversation with affordances Helps inform devices what is possible based on the last request Buttons at the bottom of Slack based on access role WITHOUT HARDCODING THE CLIENT WILL WE CONSIDER HYPERMEDIA, or FORCE CLIENTS to hardcode behavior based on response data payloads?
- More freedom for clients to be extended with new capabilities at runtime - with limited or no changes by the client
- Github is the most common example This is Slack’s event types page – 50+ The conversation changes dramatically when you open up events
- Events enable bi-directional communication WITH HYPERMEDIA LINKS Event streams and webhooks – Github and Slack Persistent/guaranteed delivery vs. best try Creates more loosely-coupled APIs Common for IoT and microservices
- Emerging standard for defining and documenting Async APIs Hitch
- Very different than how we interact from a mobile or web app NO WHERE DO YOU SEE “CREATE, READ, UPDATE, or DELETE THIS ROW”
- Survey – How many manage development with user stories? How many say it is working well for development? What about the end user? TRIGGER-BASED, COMMAND-DRIVEN, OUTCOME-BASED – Not HTTP and webhooks
- Amazon Echo Show
- Should APIs know how to render its data? Yes, but it depends. If it is conveying the representation of the resource, then yes. If it is driving an entire user experience, then no
- The intents are within the context of the session
- The one-API-fits-all approach doesn’t work As soon as the front-end needs a change to an API to drive a better user experience, conflict ensues Workflow for more details – HYPERMEDIA and HATEOAS
- How many familiar?
- Network Attached Storage from Synology allows you to install and manage network services Including Docker containers
- Local AWS Lambda – FUNCTIONS COME CLOSER TO THE DATA
- 1 interface, multiple impls - unlike today’s SaaS where we offer one implementation per interface (Lamport clock, other strategies) – similar to peer-to-peer solutions spread across the world rather than within a specific cloud vendor
- Currently, the assumption is that bots are talking to humans Chatbots at this stage in their evolution are more about ‘query and response’ The “AI” is in understanding the meaning of the query and deciding how best to respond
- The better bots get communicating, the better our software is likely to consume them
- CORBA – distributed components for system interoperability needs SOAP – distributed computing over HTTP driven by integration needs JSON + HTTP – distributed computing for billions of devices
- Question #1: How do you suggest teams begin to prepare for these new requirements for API design? Outside-in design from the user perspective Question #2: Why do you see hypermedia as a key factor in supporting these new API consumption channels? Conveys rich amounts of details with a single link, rather than through interpreting the state of data on the client-side