Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Asynchronous APIs: robust APIs in the post-REST world

Asynchronous APIs: robust APIs in the post-REST world

REST, the king for inter-service APIS is not longer enough. In this talk I go over the design limitations of RESTful APIS and the alternatives to build production-ready APIS.
Presented at APIDAY MADRID 2017

Enrique García Navalón

October 11, 2017

More Decks by Enrique García Navalón

Other Decks in Programming


  1. All begins with a very simple service... Teams and users

    Billing Stripe MongoDB Teams and users Billing MQ WebApp Admin Portal Other services Other services
  2. But REST is cool! Isn’t? • REST -> representational state

    transfer, technique for interoperability ◦ Client-server ◦ Cacheability ◦ Stateless ◦ Hypermedia as the engine of application state (HATEOAS) • RESTful -> Architecture style virtually always on top of HTTP protocol ◦ Use HTTP verbs (request methods) to provide meaning to the request itself ◦ Use HTTP response codes to provide meaning to the response itself
  3. The problems with RESTful APIs - semantics • There is

    no “official” standard. REST is an architecture style, not a protocol • Little agreement on what HTTP error codes really mean • The REST vocabulary is not fully supported everywhere • The REST vocabulary is not rich enough for APIs • HTTP is NOT extensible!
  4. Guess the REST! If there are no posts, what should

    be the answer to GET /posts/list ? A) 404 Not found B) 204 No content C) 200 OK + JSON body with empty list
  5. Guess the REST! If there is no post with id=1,

    what should DELETE /posts/1 return? A) 200 OK B) 404 Not found C) 304 Not modified D) 417 Expectation failed
  6. The problems with RESTful APIs - complexity • Our backend

    code is not resource oriented • HTTP is hard ◦ GET and POST only syndrome ◦ 200 OK only syndrome • Request/Response information in many places • RESTful APIs are hard to debug
  7. Guess the REST! GET /posts/12 returned 404 Not found. What

    happened? A) A post with id=12 is not present on the server B) The endpoint /posts doesn’t exist in the server
  8. The problems with RESTful APIs - architecture • RESTful APIs

    coupled to HTTP ◦ But we are sending JSON payloads... • Only one type of communication: client-server request-response ◦ No publish/subscribe, notification, etc. • HATEOAS constraint is hard to implement ◦ But provides little benefits!
  9. RESTful APIs are not a good choice for • Realtime

    • Efficient querying • Microservices • Asynchronous communication • One-to-many communication HTTP Limitations!
  10. What are the alternatives? • Real-time Infrastructure as a Service

    -> Firebase, RethinkDB • New query languages -> GraphQL, FALCOR • REST-over-WebSocket-kindof APIs -> Emulate REST using JSON payload • Message Queues Protocols -> MQTT, AMQP, STOMP • The good old Remote Procedure Call-> gRPC
  11. Introducing AsyncAPI specification • Machine-readable definitions for message-driven APIs. •

    Protocol-agnostic, so you can use it for APIs that work over MQTT, AMQP, WebSockets, STOMP, etc. • Heavily inspired on OpenAPI. Designed to maintain as much compatibility as possible with it. • Who -> Hitch, an API support platform for API providers • Why -> To be able to provide their services to message-driven APIs
  12. The new stuff vs OpenAPI • The path concept disappears,

    we only need the server URL • New concept, topics ◦ Basically the same of HTTP URIs but protocol-agnostic ◦ Namespace for routing in MQ protocols -> routing key, destination, etc. ◦ Allows to define public and/or subscribe • New concept, messages ◦ A piece of information two or more programs exchange ◦ Describes the payload of the message in both requests and responses+ • New attribute scheme, servers must declare their protocol • Simplified Components Object, only messages, security and schemas
  13. Maturity • Young -> Released <6 months ago • Small

    community -> ~50 GitHub stars • No big (public) project yet • Only one API platform supports it -> Hitch • Tooling -> documentation generator, Node code generator, online editor WIP • Strongly based on OpenAPI -> not reinventing the wheel (too much) • Very specific to MQ protocols but has an extension system
  14. Final thoughts • RESTful APIs are not the best tool

    out there for Web APIs • Message-driven APIs are being used successfully in other areas • Why not use an unified architecture for all cases? • OpenAPI for message-driven APIs -> AsyncAPI • Not a drop-in replacement! More like an extension • AsyncAPI is in early stages but is a good starting point • The best technology is not the coolest one is the one that solves the problem
  15. References and further reading 1. HATEOAS and Hypermedia: a. http://www.amihaiemil.com/2016/05/07/what-is-hateoas.html

    b. https://jeffknupp.com/blog/2014/06/03/why-i-hate-hateoas/ c. https://vimeo.com/20781278 d. http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven 2. JSON-pure APIs a. https://mmikowski.github.io/the_lie/ b. https://mmikowski.github.io/json-pure/ c. http://jsonapi.org/ 3. Query-efficient APIs a. http://graphql.org/ b. https://netflix.github.io/falcor/ 4. Machine-readable documentation for APIs a. https://www.asyncapi.com/ b. https://www.openapis.org/ 5. Interprocess communication a. https://www.nginx.com/blog/building-microservices-inter-process-communication/