REST API with HTTP/2

Question

Couple of months ago, HTTP/2 was published as RFC7540.
How will this affect the existing REST API built on HTTP/1.1?

As per Wikipedia, HTTP/2 has added new features.
How can we take advantage of these new features?

Khalil

Answer 1

The main semantic of HTTP has been retained in HTTP/2. This means that it still has HTTP methods such as GET, POST, etc., HTTP headers, and URIs to identify resources.

What has changed in HTTP/2 with respect to HTTP/1.1 is the way the HTTP semantic (e.g. "I want to PUT resource /foo on host example.com") is transported over the wire.

In this light, REST APIs built on HTTP/1.1 will continue to work transparently as before, with no changes to be made to applications. The web container that runs the applications will take care of translating the new wire format into the usual HTTP semantic on behalf of the applications, and application just see the higher level HTTP semantic, no matter if it was transported via HTTP/1.1 or HTTP/2 over the wire.

Because the HTTP/2 wire format is more efficient (in particular due to multiplexing and compression), REST APIs on top of HTTP/2 will also benefit of this.

The other major improvement present in HTTP/2, HTTP/2 Push, targets efficient download of correlated resources, and it's probably not useful in the REST usecase.

A typical requirement of HTTP/2 is to be deployed over TLS. This require deployers to move from http to https, and setup the required infrastructure to support that (buy the certificates from a trusted authority, renew them, etc.).

Flagelliform

So you don't have to change anything regarding the web application / api? Just configure it on the server (including TLS) and it works right? – Ringsmuth

Correct. I can't speak for every web server out there, but for Jetty (I am a committer) you just configure Jetty with the http2 module and you are good to go. – Flagelliform

There is a verbatim copy of this in a DZone article by an author named Guy Levin: dzone.com/articles/benefits-of-rest-apis-with-http2#20 (or is it the other way around, just looking the dates here...) – Sunflower

This is a good summary but one addition: Server Push is incredibly useful for REST APIs, it changes everything, solved under/over-fetching too. apisyouwonthate.com/blog/… Vulcain leverages the newer Preload header to let the client pick the pushes they want. github.com/dunglas/vulcain#pushing-relations – Screak

@Phil What can server push do that web sockets couldn't do for years already? I've yet to see any real advantage of HTTP/2 over 1.1 for REST APIs. – Jessie

A quick google will cover this for you. Lots of answers on here too. – Screak

HTTP/2 doesn't require you to use TLS – Potion

Answer 2

HTTP/2 spec intentionally did not introduce new semantics for application programmer. In fact, major client-side libraries (NSUrlSession on iOS, OkHttp on Android, React Native, JS in browser environment) support HTTP/2 transparently to you as a developer.

Due to HTTP/2 ability to multiplex many requests over single TCP connection, some optimizations application developers implemented in the past, such as request batching would become obsolete and even counter-productive.

Push feature would likely be utilized to deliver events and will be able to replace polling and possibly websockets in some applications.

One possible application of server push feature in HTTP/2 to REST APIs is ability to accelerate legacy applications on i.e. reverse proxy level by pushing anticipated requests ahead of time to the client, instead of waiting for them to arrive. I.e. push answers to user profile, and other common API calls right after login request is complete.

However Push is not yet widely implemented across server and client infrastructure.

Spirula

I guess HTTP/2 does introduce some new semantics (such as Server Push), but it doesn't change any of the existing HTTP/1.x semantics, so it is backwards compatible. Thus web applications can be transparently upgraded to HTTP/2. – Cloudcapped

Answer 3

The main benefit I see is Server Push for hypermedia RESTful APIs, which hold references to resources, often absolute domain-dependent URLs such as /post/12.

Example: GET https://api.foo.bar/user/3

{
  "_self": "/user/3"
  "firstName": "John",
  "lastName": "Doe",
  "recentPosts": [
    "/post/3",
    "/post/13",
    "/post/06
    ]
}

HTTP/2 Push can be used to preemptively populate the browser cache if the server knows the client will likely want to do certain GET requests in the future.

In the above example, if HTTP/2 Server Push is activated and properly configured, it could deliver /post/3, /post/13 and /post/06 along with /user/3. Successive GETs to one of those posts would result in cached responses. Also, the cache digest draft would allow client to send information about the state of their cache, avoiding unnecessary pushes. This is much more practical for Hypermedia-driven APIs then embedded bodies such has does HAL.

More information on the reasons here: The problems with embedding in REST today and how it might be solved with HTTP/2.

Bornite