Rest is an architectural style and is not a protocol

Question

I read that Rest is an architectural style and is not a protocol. I would appreciate if someone can elaborate on this. Thanks

Answer 1

I read that Rest is an architectural style and is not a protocol. I would appreciate if someone can elaborate on this.

From Fielding's thesis

An architectural style is a coordinated set of architectural constraints that restricts the roles/features of architectural elements and the allowed relationships among those elements within any architecture that conforms to that style.

The overview of the architectural constraints that make up the REST architectural style are described in section 5.1

It may also help to review Fielding's presentation REST in AEM, where he calls out specific misunderstandings of what REST is.

In contrast, if you look at the introduction in RFC 7230, you'll see it opens with

The Hypertext Transfer Protocol (HTTP) is a stateless application-level request/response protocol that uses extensible semantics and self-descriptive message payloads for flexible interaction with network-based hypertext information systems.

You might look to Jan Newmarch's Network Programming in Go, which includes a chapter on application-level protocols.

A protocol defines what type of conversation can take place between two components of a distributed application, by specifying messages, data types, encoding formats and so on.

REST, you'll note, doesn't specify any of these -- it only constrains the choices you can make.

Answer 2

A protocol usually describes the exact messages (or parts thereof) the two (or more) peers have to exchange. Specifying also the choreography how these messages are exchanged and what they mean.

An architectural style (like REST) does not describe messages at all, but specifies requirements (architectural constraints) that the messages, choreography or parts of the system have to fulfill.

So while a protocol might say: "use JSON in the following format to request a quote". An architectural style just says: "clients can contact servers, but not the other way". It's a completely different level.

Here is how they are related: An architectural style is like a template for a specific architecture. A specific architecture in turn defines the protocols between components.

Answer 3

A good analogy is to think of a protocol as how to write a message and REST as how a machine deals with a message it receives.

Think of a protocol as defining how data between two endpoints is organized. There are several different protocols like HTTP, TCP, IP and ARP. What all of them have in common is that they represent a standard for how to define data in a universal way such that any machine running a program that can interpret data through those protocols will interpret a signal the correctly and precisely. In each case, every time you send out a request your sending out binary to a network (which can include the internet). The binary representations are configured in such a way that they are messages configured in a protocol such as HTTP depending on which layer of networking layer your focusing on (HTTP is in the application layer and you can read more here: OSI model).

REST, on the other hand, handles data sent to endpoints based only after its message has been interpreted. In other words, a message is received, that message is translated into commands, those commands are executed, a response is generated and that response message is translated using a protocol (usually HTTP in the application layer) which is then sent back as a response.

When point A sends a request to a REST API architecture at point B it first translates that data into a standardized protocol (e.g. HTTP at the application layer and others as needed) then sends that message through a network until it reaches point B. When point B receives that data it translates that data and passes it into its REST API which interprets the data as commands and runs their specific functions. After the functions rub by the API are complete, it encodes data again using a protocol and sends a response back to point A.

You can think of it like this. The protocol creates the message so it can be sent and understood. REST is responsible for ensuring the server does operations expected of it not defining the standard for how the data is to be organized so it can be recognized by all possible end points.

There are some good references here:

Communications Protocol

Representational state transfer

It's complicated and takes a while to grasp. There's a lot more to it than what I've shown here but hopefully it serves as a good starting point for you.