REST API with HTTP/2

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?

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 domain.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.).

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.

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.