Downloaded 17 times
Uploaded byLaunchAny
Austin API Summit 2018: Are REST APIs Still Relevant Today?
The document discusses the relevance of REST APIs in 2018, highlighting their various applications and interaction styles. It reviews the evolution of APIs from the 1990s through current common styles, including GraphQL and gRPC, while outlining challenges and advantages associated with each. The presentation emphasizes the importance of understanding business problems and leveraging HTTP capabilities effectively rather than focusing solely on coding.
More Related Content
![[apidays Live Australia] - Quantum Duality of “API as a business and a techno...](https://cdn.slidesharecdn.com/ss_thumbnails/asanka-2021-apidays-cdbata-auz-asanka-v1-210922090858-thumbnail.jpg?width=640&height=640&fit=bounds)
Similar to Austin API Summit 2018: Are REST APIs Still Relevant Today?
Austin API Summit 2018: Are REST APIs Still Relevant Today?
- 1. Are REST APIsStill Relevant Today? 13 June 2018 @ Austin API Summit James Higginbotham @LaunchAny
- 2. 2 Introduction • API Strategy,Program Execution, Training – API design – Microservices – Containerization • Recent Projects – Enterprise IT – SaaS – From 100s to 10s of thousands of developers – Variety of verticals
- 4. 4 APIs Solve aVariety of Use Cases Customer Experience Worker Experience Supplier/Partner Experience
- 5. 5 APIs Offer DifferentInteraction Styles Request/ Response Request/ Acknowledge Batch Publish/ Subscribe Message Streaming
- 6. 6 APIs: Looking Backat History
- 7. 7 The Road SoFar… 1990s RPC & Distributed Object Integration
- 8.
- 9. 9 The Road SoFar… 1990s RPC & Distributed Object Integration 2000s Corp-to-Corp Integration
- 10. 10 SOAP Protocol Support:Tunneling through HTTP, SMTP, JMS Source: https://stackoverflow.com/questions/15705892/what-is-the-purpose-of-ws-addressing
- 11. 11 SOAP w/ AsynchronousCallbacks Source: https://docs.oracle.com/cd/E15523_01/web.1111/e15184/asynch.htm
- 12. 12 The Road SoFar… 1990s RPC & Distributed Object Integration 2000s Corp-to-Corp Integration 2010s + Mobile/Data Integration
- 13. 13 The Power ofthe HTTP Protocol for APIs
- 14. 14 The Basics: URLs,Headers, and HTTP Methods Method Safe (Side- Effect?) Idempotent GET Yes Yes POST No No PUT No Yes PATCH No No DELETE No Yes HEAD Yes Yes
- 15. 15 Content Negotiation: SupportingMultiple Content Types GET https://api.example.com/projects HTTP/1.0 Accept: application/json;q=0.5,application/xml;q=1.0 HTTP/1.0 200 OK Date: Tue, 16 June 2015 06:57:43 GMT Content-Type: application/xml <project>…</project> 15
- 16. 16 Language Negotiation: SupportingMultiple Languages GET https://api.example.com/projects HTTP/1.0 Accept-Language: en;q=0.5,de;q=1.0 HTTP/1.0 200 OK Date: Tue, 16 June 2015 06:57:43 GMT Content-Language: en <project> <status>active</status> <status-display>active</status-display> </project> 16
- 17. 17 Language Negotiation: SupportingMultiple Languages GET https://api.example.com/projects HTTP/1.0 Accept-Language: en;q=0.5,de;q=1.0 HTTP/1.0 200 OK Date: Tue, 16 June 2015 06:57:43 GMT Content-Language: de <project> <status>active</status> <status-display>angenommen</status-display> </project> 17
- 18. 18 Client-Side Caching: ImprovingApp Performance Source: https://developers.google.com/web/fundamentals/performance/optimizing-content-efficiency/http-caching
- 19. 19 Intermediary Caching: ReducingNetwork Latency with Proxies and CDNs Source: https://www.maxcdn.com/one/visual-glossary/proxy-caching/
- 20. 20 Conditional Requests: StayingUp-to-date Source: https://developer.mozilla.org/en-US/docs/Web/HTTP/Conditional_requests
- 21. 21 Concurrency Control: ProtectingResource Integrity with Optimistic Locking Source: https://developer.mozilla.org/en-US/docs/Web/HTTP/Conditional_requests
- 22. 22 “The Power ofHTTP for APIs” 2-part series: http://bit.ly/power-http
- 23. 23 A Look atToday’s Common API Styles
- 24. 24 Popular API Stylesin 2018
- 25. 25 GraphQL Example: POSTquery Source: https://blog.octo.com/en/graphql-a-new-actor-in-the-api-world/
- 26. 26 Advantages of GraphQL Hierarchical DataSupport Field-Level Selection Strong Typing Good Fit for Front-End APIs Introspection
- 27. 27 Challenges for SomeGraphQL Implementors Limited Endpoint Security Enforcement Limited Ops Tooling Inconsistencies in Recommendations Lack of Flexibility for Content Types Lack of Cacheability
- 28. 28 Popular API Stylesin 2018
- 29. 29 gRPC: Example ServiceDefinition, Server, and Client Source: https://grpc.io/docs/quickstart/node.html
- 30. 30 Advantages of gRPC HighPerformance/ Low Latency Protobuf Message Format Code Generation (client and server) Bi-Directional Communication Built On HTTP/2
- 31. 31 Challenges for SomegRPC Implementors Limited Error Handling Limited Dev/Ops Tooling Inconsistent Code Gen Across Languages Lack of Flexibility for Content Types Lack of Cacheability
- 32. 32 Popular API Stylesin 2018
- 33. 33 REST APIs arestuck in the land of CRUD
- 34. 34 Revisiting the RESTConstraints Client-Server Stateless Cache Layered System Code on Demand (optional) Uniform Interface (resources, representations, hypermedia)
- 35. 35 Deep-Dive: REST’s Layeredand Cache Constraints Logging AccessManagement RateLimiting Caching Custom APIImplementation LoadBalancer CDN/EdgeCache Client Network Infra API Management Layer Your Code Client Cache HTTP HTTP HTTP HTTP
- 36. 36 HTTP HTTP HTTP OperationalizingYour API: There is more to your API than code! Logging AccessManagement RateLimiting Caching Custom APIImplementation LoadBalancer CDN/EdgeCache Client Network Infra API Management Layer Your Code Client Cache HTTP
- 37. When APIs MeetJobs-To-Be-Done { … "_links": { “self": {"href": "/approval-requests/d796f2d0eb72492bb088"}, “approve": {"href": "/approval-requests/d796f2d0eb72492bb088/approve"}, “decline": {"href": "/approval-requests/d796f2d0eb72492bb088/decline"}, }, … }
- 38. 38 Popular API Stylesin 2018
- 39. 39 Webhooks, SSE, andMessage Streaming
- 40. 40 Some Things Change,But Some Stay the Same +
- 41. 41 Are REST APIsStill Relevant?
- 42.
- 43.
- 44. 44 #1: We mustspend time to understand the business problem first, not the technology
- 45. 45 #2: We allmust become better educated with what HTTP has to offer, rather than reinventing the HTTP protocol over-and- over (then tunneling it via HTTP)
- 46. 46 #3. Evolve ourtools and frameworks to better take advantage of HTTP: caching, concurrency control, hypermedia
- 47. 47 #4. Our thinkingmust move ”beyond code on the laptop” and into business use cases, ops, compliance, and support concerns
- 48. 48 #5. Stop using‘vs.’ and start using ‘and’ when it comes to selecting API styles
- 49. 49 Moving the MindsetFrom “vs.” to “and” + + + + +
- 50.
Editor's Notes
- #4 If it is just about Google search volume, REST wins – thanks for listening! But, it isn’t just about search volume…
- #6 Our APIs also support different use cases indirectly. That, combined with the context in which they are used (external, internal, operational) and interaction styles results in a large variety of API contexts we must support. It stands to reason then that not any one API style can meet all of these needs. Let’s step back and review some history, see how we solved for these needs in the past, and how modern API styles can help us solve today’s needs
- #7 Before we look at today’s API styles, it is important to look over our shoulder at some recent styles that we have used (and some continue to use)
- #8 Early days we used RPC and CORBA – distributed components for system interoperability needs
- #9 ORB (Object Request Broker) was middleware ($$$) that handled network protocols and offered code generation tools based on IDL (interface definition language). Solved the need to bridge various programming languages and try to achieve system-to-system interoperability. It worked – to a point – but still struggled with interoperability along with the fragility of integrating directly with code from our objects
- #10 Enter SOAP – distributed computing over HTTP driven by integration needs
- #13 JSON + HTTP – distributed computing for billions of devices
- #15 HTTP Methods are NOT about CRUD
- #16 Q-factors allow for specifying multiple supported types
- #17 English if German not supported
- #18 Otherwise, we can receive German angenommen = ”active” in German
- #26 All tunneled through HTTP/POST Started by who? Facebook – the company that stores a huge world-wide graph of profiles and relationships! Github adopted because – they have a huge graph of repositories, owners, and corresponding relationships!
- #27 Reference CORBA, show that middleware was removed in favor of OSS generators, HTTP/2 used for protocol
- #28 GraphQL ignores the web and just uses HTTP POST for tunneling – much like SOAP Based on some case studies I reviewed, there have been a few challenges encountered: Dev/Ops tooling – the optimum path for GraphQL is for front-end developers. Little attention is paid to operational concerns, side-steps many of the benefits of HTTP Cacheability – POST used for all queries, no etag support No concurrency support; Currently JSON-based
- #30 HTTP/2 POST Bi-directional support
- #31 Reference CORBA, show that middleware was removed in favor of OSS generators, HTTP/2 used for protocol
- #32 gRPC depends highly on code generation and ties clients tightly to server code, like CORBA did. Interoperability became an issue as people deviated Based on some case studies I reviewed, there have been a few challenges encountered: Dev/Ops tooling – the optimum path for gRPC is for backend developers. Little attention is paid to front-end devs and operational concerns Relies on the strength of code generators and community that drives them
- #34 As I train organizations, I see the same common problem: we are stuck in CRUD. If we can build CRUD APIs in 15 minutes, we tend to push implementation concerns and data joining to the consumer-side. We need to ask ourselves if we value our API consumers. They don’t want to manage a database over HTTP.
- #35 Client-Server and Stateless are common. Uniform Interface, Cache, Layered start to differentiate REST from others
- #36 If the layered constraint is properly applied, middleware can be added to load balance requests, apply rate limits, enforce security, add caching. This is only possible if we utilize HTTP to the fullest! When we tunnel through HTTP using POST, as we do with GraphQL and gRPC, we make this more difficult to operationalize Without it, this is pushed to the codebase or, at best, the edge of the API rather than the edge of the network (closest to the devices)
- #37 BTW, this diagram reveals a big reality check: there is more to writing an API than your code! You must pay attention to the operationalization side as well! From caching to security, rate limiting, load balancing – all of it! A fancy new API style may or may not be easy to make production-ready!
- #38 More FREEDOM for clients to be extended with new capabilities at runtime - with limited or no changes by the client Requires us to understand HTTP deeply and apply THOUGHTFUL design considerations
- #41 gRPC learned from CORBA, moved to HTTP/2 for scale GraphQL blends SOAP with HTTP+JSON
- #42 Let’s consider the kinds of software we see emerging, and how APIs will drive
- #46 As we talked about earlier – HTTP is powerful, but only if we seek to understand it better
- #47 Our tools, frameworks must adapt to use more of the HTTP protocol. Some are designed to do so through plugins/extensions. Others, not so much
- #48 We must consider all areas of software design and architecture – especially going beyond the code that runs on our laptop
- #49 Vim vs. Emacs .Net vs. Java REST vs. GraphQL
- #50 REST is a great foundation for many shared APIs when the constraints and patterns fit – resources, course grained, built directly upon HTTP But it doesn’t have to be the only choice