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