Should we rebrand REST?
In this blogpost I argue the case for consigning the term "REST API" to history. In its place we should adopt the terms "HTTP API" and "hypermedia API", which better differentiate two distinctive design conventions for the programmatic interfaces of web services.
At a high level, you'll want to consider which general style of API (REST, RPC, graph, etc) will be the best-fit for your application's business domain. You'll want to settle on a transport protocol (which will probably be HTTP but you might consider WebSocket, or both). And you'll need to choose between a medley of generic serialisation standards (JSON and XML lead the field here), or you might opt for a specialist messaging protocol with plain text (SOAP, OData, GraphQL) or binary message encoding (Thrift, Avro, Protocol Buffers).
REST is just the coolest thing in web service API design right now, isn't it? In recent years, whenever organisations have wanted to publish new public web services, they've customarily turned to REST as the go-to architectural style for their APIs, shunning alternative approaches like SOAP or various RPC conventions.
