A presentation comparing RESTful APIs with Websockets, webhooks, and discussing gRPC. We also look into the history of HTTP v1 and v2 and look ahead to HTTP v3, and how those affect our API performance.
industry (engineer, mgmt, director) 8 years in advocacy 4 years as an educator hobbies: - dog training - 3d printing, airbrushing - career coaching - dad jokes Yesterday, I was washing the car with my son. He said, "Dad, can't you just use a sponge?" @getpostman @iandouglas736 I’ve been in the tech industry a long long time. Most of my gray hair comes from working at over a dozen startups and having two teenagers. I’ve spent over 8 years in the advocacy space, 4 years of which were in education teaching people about development. On the side, I’m also really into dog training, 3d printing, career coaching, and wow do I love some dad jokes. The more awful the better, so if you have any you want to share, please tag me on social platforms, my handle is at the bottom of the slides, iandouglas736. I have a lot of them on the bottom of my slides, so when you start laughing at me, I can lie to myself that you’re just laughing at the jokes on the slides, and not at my talk.
Standards @getpostman @iandouglas736 What do you call a wizard who is bad at rugby? Fumbledore. REST - defined in 2000 RESTful came shortly after, though there’s no easy ay to determine when the term itself came to be – happened because people didn’t like following such strict rules, they wanted SOME flexibility in what they built Most schools are teaching about RESTful APIs, though mostly on the consumption side. Postman has a student program where we work with schools to get students using Postman and learning about other API architectures.
a “representation” of the action you want to take on a resource, like fetching/deleting data. • State HTTP is “stateless”, it doesn’t remember you from one action to the next, so we mimic state by using ID values or headers in our RESTful calls. • Transfer RESTful APIs typically work on a single request-response cycle – I connect, I ask for one action, I disconnect. What is REST – a brief history REST: REpresentational State Transfer @getpostman @iandouglas736 Image credit: https://dev.to/asdflkjh/restful-api-b4i What does REST stand for What is “state” HTTP has been around since 1991 Example about single-transaction transfer, like a phone call
in JSON was more adaptable. • Scalable Clients can scale separately from Servers, allowing for easier expansion, and creation of microservices. • Flexibility Browsers as clients, data in various formats, combination of HTTP methods, Headers and Resource IDs allow for greater creativity. Why is RESTful so popular in our industry? Growth from 2005 to 2013 was greater than other API types, giving it a foothold @getpostman @iandouglas736 Where do I see myself in five years? I think we’ll still be using mirrors … REST outgrew other popular protocols like SOAP Flexibility: For better or worse, it was a lot of “wild wild west” out there, with everyone trying to define their own idea of a standard for their own company, something we call “Governance” in the industry.
very sensitive to high-latency connections, and uses a single TCP entry point. • HTTP v1-and-done Clients connect, ask for a single action, then disconnect. Also, servers cannot interrupt clients if they try to send too much data. • Inefficiencies in Fetching RESTful APIs are prone to under-fetching or over-fetching data, resulting in more single-request calls, or discarded data. Why Look at Anything Else? If REST is so great, why do we even have other API types? @getpostman @iandouglas736 As popular as it has been, RESTful APIs seem a little stuck in HTTP 1.1 territory and needs to keep up with technology. Companies like Google started introducing new protocols like SPDY which was the basis for HTTP 2.0 Interruption: phone call with my mother in law Fetching: this is why technologies like GraphQL came on the scene, allowing the CLIENT to specify which fields to return as part of the request; this could also happen in REST with parameters, etc.
data into “messages.” • Better Compression of Data HTTP/2 uses stronger compression when sending data, resulting in faster transfers. • HTTP Still Disconnects Afterward Clients and Servers still disconnect after transfers are complete, per HTTP. No way to “push” event-driven data. • HTTP/2 front-end Adoption is Low Browsers support HTTP/2, JS Fetch supports it, but most data transfers are still sending text-based JSON data. Can we fix any of that? Could we move RESTful APIs to HTTP v2 (aka HTTP/2) and just … fix these problems? @getpostman @iandouglas736 I would love to tell you a UDP joke, but you may not get it. Moving to HTTP 2 isn’t just a software change in your API, it’s an infrastructure change for your DevOps team to support as well. Compression: gzip
provide a callback mechanism or external system to ping. Connections can also be held open indefinitely to stream data over time. • Promises, Promises Asynchronous clients, like JavaScript Promises, allow event loops to be notified when something is done. • A-Wait a Minute … You CAN tell your code to wait for an asynchronous API answer before continuing your other work. Event-Driven Architecture If THIS, then THAT … @getpostman @iandouglas736 I’ve been reading a book about anti-gravity – I can’t put it down! The idea of Async APIs is that they are event driven, and there are two classic methods of Async APIs: webhooks and websockets. They are still HTTP-based, so they make a connection, transfer data, and disconnect. Websockets, unlike RESTful APIs and Webhooks, can keep a connection open for long periods of time, alerting either side with packets of data when events happen. We see this most commonly in chat mechanisms, where many users can connect and get real-time updates when someone writes a message for example. But developers don’t necessarily need to pause and wait for a response before continuing their work. Event loops like Promises and other mechanisms called async/await allow developers to choose when to pause execution to wait for a response or not.
or PayPal processed an incoming payment for you. • Making “Fetch” Happen (websockets) JavaScript fetch calls are great for processing responses whenever they happen. Really handy for eventual UI/UX patterns. • Lots of Choices Lots of protocols to choose from, like Webhooks, Websockets, GraphQL Subscriptions, Server-Sent Events. (Web)Hook, Line, and Sinker Where do we see ASync APIs used most? @getpostman @iandouglas736 Most typically, we see webhooks used in a response mechanism. For example, someone pays an invoice with PayPal, and PayPal can call a webhook that you specify that can take some other action like updating your CRM system. As mentioned earlier, Websockets are commonly used for more real-time applications where you need to hold that connection open and have a conversation. There may need to be some amount of “state” exchanged on connecting, or reconnecting, to resume where you last left off, such as “which message did we see last time” for a real-time chat mechanism. GraphQL has also included a streaming data mechanism they call Subscriptions, it’s a little bit like the publish-subscribe pattern, which we sometimes call pub/sub. There are lots of other choices here, including a newer mechanism called server-sent events where servers can push new data to a client, again, because these asynchronous channels are held open.
server-side, Async APIs can sometimes be more challenging to plan and design. • Are Webhooks just RESTful in reverse? Is your client acting like a server that the real server connects to to send data later? There can be confusion about the architecture and how event loops really work. • Some aspects are challenging Rate-limiting, throttling data, tracking analytics, even some aspects of security are more difficult with Async APIs. Disadvantages of Async APIs Are they better than RESTful? @getpostman @iandouglas736 shameless plug: now would be a great time to tweet to @getpostman about how great my talk is going. Async still has its problem areas though, it can be harder to design and plan since you don’t know which events are happening in any particular order, so you might need to reconcile data on either end of the connection to ensure everything was completed. Webhook mechanisms need to ensure that whatever system is calling it can actually route to that server, which is tricky with trusted internal network mechanisms. There are other issues you can run into, including rate-limiting and throttling data, that can be more challenging.
Data Transfer HTTP 1.1 (usually) HTTP 2 (usually) Getting a Response Client waits for a response Client provides a means to respond later (webhooks) or event-loop listener Design Complexity Lower (usually) Medium (usually) Handling requests and responses in order Predictable Not Predictable Typical Use cases General-purpose, single transaction Messaging, social media, mobile games, banking Data Structure Text or Binary, but not both Text and Binary together if using HTTP/2 REST vs Async @getpostman @iandouglas736 You can pause on this screen if you want to look at some of the primary differences between RESTful APIs and Async APIs as far as the data transfer mechanisms, design complexity, use-cases, and so on.
@getpostman @iandouglas736 No, we can’t build streets out of LEGO bricks – too many road blocks! Let’s talk about API performance and some things to take into consideration when we need to take the best things out of RESTful APIs and ASync APIs.
APIs, but it’s often more complicated and presents other challenges. • Our Powers, Combined! Are technologies available that can take the better parts of REST and Async APIs? • Above and Beyond What if we could make an API that was faster for performance, allowed sync OR async, choose whether to be stateful, and MORE? Performance Architecture Can’t we just scale REST or Async APIs to make them faster/performant? @getpostman @iandouglas736 We could, of course, just scale our hardware to add more systems to handle load, and that will help with a little bit of performance, but that raises other concerns and problems especially with the cost of cloud computing providers. How can we combine the best of the API architectures we’ve mentioned so far, like controlling our data, and handling streamed data? What if there was an API type that gave us the flexibility of single-request-response like REST, OR the ability to stream data in either direction client to server, or both, AND also allow those connections to stay open for long periods of time, but also gave you a major performance boost to speed while minimizing your data throughput? Sound too good to be true?
of flexibility to incorporate most of the benefits of REST and Async APIs. • HTTP/2, binary messaging Compression, stateful, multi-message, sync or async, so many choices! • Built with performance in mind On average, 7x to 10x more performant, mostly from HTTP/2’s stronger compression, binary format, and multi-message “streams”. Gee … RPC Google to the rescue? @getpostman @iandouglas736 For sale: Used taxi cab. It's in fare condition. gRPC was developed by Google in 2016, and is built atop HTTP version 2. This allows for long-lived connections similar to websockets, and utilizes a binary-only data approach by default. It’s still a work in progress, and there are not too many public-facing gRPC APIs out there yet, but we are seeing growth here. gRPC has 4 data transfer mechanisms, the first is very much like a RESTful API of a single request/response and disconnect. The others are a combination of the client wanting to stream data to the server, or the server streaming data back to the client, or streaming in both directions. The idea of streaming here is that you can send multiple requests or responses at any time as events occur on either end of the connection. It’s typically 7 to 10 times more performant than RESTful APIs, mostly because of HTTP version 2, and allows for lots of communication back and forth between client and server before disconnecting.
to message formatting is more difficult to plan. Not usually found in public-facing APIs. • Relies heavily on HTTP/2 HTTP/2 is great, but still has its own issues, which HTTP/3 will fix. (eventually…) • Third-party tooling is still new-ish Library and language support is still relatively new for various tech stacks. Some code generators exist, but tools are still in their infancy. Disadvantages of gRPC Because nothing’s perfect … @getpostman @iandouglas736 Adoption of gRPC is low, but we are seeing growth. At Postman, we’re mostly seeing gRPC APIs happening within internal networks to communicate server to server, not so much from an end user client like a browser. Because it’s based on HTTP/2, and using protocol buffers, you need some proxy libraries in JavaScript to communicate with gRPC from a browser. We’ll see improvements here over time. HTTP/2, as an aside, has its own issues around DOS attacks and security issues, which are being addressed in HTTP/3 which is already out, but HTTP/2 isn’t even well adopted itself yet, so there may be more changes to gRPC and even async APIs over time as problems with HTTP/2 are addressed. As time goes on, the tools will get better, and gRPC is definitely worth the time to investigate as a feasible solution for the minimized latency and data transfer alone.
Data Transfer HTTP 1.1 (usually) HTTP 2 Getting a Response Client waits for a response Synchronous like REST, or Asynchronous like webhooks Design Complexity Lower (usually) Higher (usually) Handling requests and responses in order Predictable Depends on sync/async Typical Use cases General-purpose, single transaction Mobile apps, server-to-server communication, event logging Data Structure Text or Binary, but not both Binary (usually) using protocol buffer messages REST vs gRPC @getpostman @iandouglas736 When I worked in cybersecurity, my favorite snack food was phish sticks. Again I’ll pause here so you can see some of the differences between RESTful APIs and gRPC APIs. gRPC APIs have a lot of commonality with Async APIs but give an extra performance boost.
in a RESTful API? BUT … @getpostman @iandouglas736 Can we implement a RESTful API on HTTP/2 to gain some of its benefits? Yeah, you can, if you want to build it. GraphQL is a bit of a mix of REST and gRPC with JSON payloads, and with their “subscribe” process it’s a little bit like async as well Can we use a binary data format that enforces data types? Absolutely, just make sure every client that ever connects to you knows precisely how to handle those messages. gRPC has a “discovery” built in that allows clients to learn about the API message payloads. Can we implement an event-driven architecture using REST? Eh, kinda, but it would still be a single request/response cycle because of HTTP, but mimicking a “stream” of incoming data certainly IS possible, that’s how we’ve managed streaming content for a few decades now. Can we do encryption by default? YES PLEASE! But now you’ve just increased the complexity of your API design, you’re made your deployment and management more complex, you’ve likely made your infrastructure more complex. Is that really worth it? So now that I’ve thoroughly confused you with all of this, we can ask the big question:
CONCLUSION @getpostman @iandouglas736 What kind of people never get angry? Nomads. Choosing an API architecture is a tricky balance of performance, but what does “performance” mean? When we think about the evolution of HTTP v1 and v2 and the improvements made, and looking ahead to some of HTTP v3’s performance is going to be interesting. HTTP 2 suffers from a latency problem where all transactions stall when a TCP packet gets dropped/reordered. And because the Internet is what it is and we can’t always guarantee that all packets from me to you are using a single communication line, then EVERYONE who is connected feels the lag. HTTP 3 is based on the QUIC protocol, build on UDP, which will reduce some of the communication chatter. It’s going to have new session management built in to mimic stateless calls while still retaining the familiar HTTP methods, headers, and status code systems. It’s actually been supported now since 2020 and 2021 in most major browsers. In fact most other libraries are fully supporting HTTP 3
something new, but … • Does your team already know the technologies? • Do they already know how to design, build and consume that type of API? • Is your infrastructure already set up to support this? Or will your infra teams need to learn something new, too? • Is there an easier migration path for performance later without a total rewrite? PERFORMANCE COMES IN TWO FORMS @getpostman @iandouglas736
a dentist is tooth-hurty. @getpostman @iandouglas736 I hope this was helpful, and I’m happy to answer any questions you have. My username on most social platforms including LinkedIn is iandouglas736 if you’d like to reach out to ask any further questions. The QR code here will also get you to my contact information. Thanks very much to Web Unleashed for having me today.
iandouglas
tkikuc
waka292
naokihaba
chinen
1024jp
tonionagauzzi
satoshi256kbyte
tsoshiro
konokenj
monochromegane
falcon8823
kaitokudou
tammyeverts
chrisshort
bcantrill
dougneiner
shlominoach
ufuk
denniskardys
kneath
lemiorhan
garrettdimon
philhawksworth
smashingmag
