What does Representational State mean in REST?

Although REST is stateless, it has state transfer in its name. It's a little bit confusing to everyone.

Stateless

When you open a web page in the browser, you will act as a service consumer and the www server will act as a service provider to serve you with a webpage. If it is a normal connection, the client and the server will both perform a handshake and initiate a session (called a TCP connection).

After that, based on the server's and client's behavior, the state will change to either ESTABLISHED, IDLE, TIMEOUT, etc. But in REST, we are using the HTTP protocol which is a stateless, meaning the server will not store any session information about the client. The client is responsible for sending all of the details required by the server to get serviced, meaning when we invoke the URI http://somedomain:8080/senthil/services/page1 from the server, it has enough details about the client to serve page1 fully.

State Transfer

Using the same example, when you open a web page using some URL to view an image file (RESOURCE) on the server,the www server will show you (the client) the image in some format i.e a REPRESENTATION of the RESOURCE (image file).

During this process, the constant resource state of the server (i.e. the state of the image file which is stored in the server database) will be represented to client in an understandable format i.e. application state of the client. So, the resource state will remain constant in respect to clients, and only the representation of the resource will change, which in turn would change the application state.

Finally, the representation of the resource (how the image is displayed to the client), which implicitly changes the state of both the server and the client is called REST.

---

Representational State Transfer refers to transferring "representations". You are using a "representation" of a resource to transfer resource state which lives on the server into application state on the client.

---

Every object has some state(data) and behaviour(methods).In order to transfer state of object on server at particular instance of time to client, some sort of representation is needed like JSON or xml or any other format.

So REST is about creating representation of object's current state and transferring that representation over network.

---

TL;DR

Representational state transfer or simply REST is a term for exchanging data in well-defined formats in order to increase interoperability. Through application of certain constraints decoupling from clients to servers should be achived which make the former one more robust and the latter one more flexible to changes.

A resource representation is the outcome of applying a mapping from the resources current state to a media types well-defined syntax and structure. It is therfore highly coupled with content-negotiation which defines the process of agreeing on a media type to transform the resources state into a requested representation (= syntax & structure).

REST can be seen as a technique to decouple clients from servers/APIs in a distributed system which gives the server-side freedom to evolve and change its structure to its needs without breaking client implementations.

In order to gain such a strong benefit a couple of preconditions need to be in place as almost nothing comes for free. Fielding here defined a couple of constraints which he further clarified (and explained) in his well known blog-post. Servers won't be able to achieve such freedom if clients don't follow the REST approach as well as clients won't be able to dynamically explore further possibilities if the server does not support clients in such. In short, both sides need to follow the same principles. If the approach is not followed stringent a direct coupling between server and clients will remain which will lead to failures if the server is ever going to change.

But how is the decoupling actually achieved?

First, a server should support a client on following its task by including URIs clients are able to use. Having a server provide all the URIs a client can invoke from the current state the client is in removes the need of the client to have a-priori knowledge of the API and how the URIs are structured.

Second, instead of letting clients interpret URIs, servers should return URIs in combination with link relation names. I.e.instead of a client using (and interpreting) a URI like http://server.org/api/orders it should use a link relation like new-order. If the server changes the URI above to i.e. http://server.org/api/new-orders for whatever reason clients using link relation names will still be able to follow their task while those using the URI directly will need an update before they are able to continue.

To my knowledge there are no standards yet where such link relation names should be defined and documented. For collection links the semantics of relation names like self, prev, next, first and last seem to be meaningful enough though something more domain specific like order or product-xyz may not. Such semantics may be described either in special media types or new standards.

Up to now these points tackle the HATEOAS constraint but unfortunately that's not all yet. According to Fieldings blog post:

A REST API should spend almost all of its descriptive effort in defining the media type(s) used for representing resources and driving application state, or in defining extended relation names and/or hypertext-enabled mark-up for existing standard media types.

Fielding further commentet that:

A REST API should never have “typed” resources that are significant to the client. Specification authors may use resource types for describing server implementation behind the interface, but those types must be irrelevant and invisible to the client. The only types that are significant to a client are the current representation’s media type and standardized relation names.

A typed resource is a resource where a client has a preassumption of the content. I.e. a client who received a URI http://server.org/api/user/sam+sample with a link relation name user determines that data belonging to that resource describe a person and therefore may attempt to marshal a application/json representation of the resource data to a Person object.

The problem with typed resources is, that clients have certain pre-assigned assumptions or knowledge on the data contained in such resources, i.e. a user resource which may vary from server to server though. While one server may expose a user name as name property an other server may use firstName and lastName and a client that wants to server each possibility is almost unmaintainable. Further, if the server ever changes its logic clients may break witha certain likelihood. To counter this coupling media types should be used instead.

Media types, which are human readable textual description of a representation format, defines the syntax used as well as the structure and semantics of available elements contained in documents exchanged in that format. Applications following the REST architectur model should therefore use established or custom media types to increase interoperability. Instead of directly coupling client and server, both couple to the media types actually. Support for such media types can be provided either through loading existing libraries or by implementing the specification from scratch. Even loading such media types dynamically through plugins is possible, if supported.

Clients and servers should use content negotiation to agree on a common media type format understood by both parties to exchange the current state of a resource. Content negotiation is achieved by providing a HTTP Accept header (and/or one of its siblings), which lists the MIME types a client is able or willing to process, within the request and by the server responding either in one of the requested formats including a Content-Type HTTP response header to inform the client which media type representation was used actually or returning a 406 failure response.

For the person example from above clients could send an HTTP Accept header with the following content: application/vcard+json, application/hal+json;q=0.6, application/json;q=0.1 to the server, wich asks the server to return the state of the resource in a syntax and structure defined by one of the listed media types. It further specifies that the client prefers receiving the state formatted according to the specification of the application/vcard+json media type description and if the server is not able to it should prefer hal+json over the traditional json syntax. The server now either maps the current resource's state to one of the requested formats or respond with an appropriate 406 failure message if either all of the requested media types are unknown or the state could not get converted to such a structure or default representation supported by the client.

To summarize, REST is a technique used to achieve high interoperability by relying on well-defined media types and to decouple clients from servers by using features like content negotiaion and HATEOAS. As reward clients will get robust to changes and thus need less maintaining in generall while server gain the benefit of being able to evolve and change without having to fear that clients wont be able to interact with it once the changes have gone live.

Certain things like standardized meaningful link relation names, custom domain-dependant media types and mapping processes to transform state into media type applicable representations need to be set up first, which is a non trivial task TBH, though once available they provide above mentioned benefits.

---

Copying from my blog

REST is about creating representation(like JSON or xml or any other format.) of object's current state(like data in database) and transferring that representation over network. Rest is the set of constraint/convention.

Resources are decoupled from their representation so that their content can be accessed in a variety of formats, such as HTML, XML, plain text, PDF, JPEG, JSON, and others. Metadata about the resource is available and used, for example, to control caching, detect transmission errors, negotiate the appropriate representation format, and perform authentication or access control

At ground level , Rest is nothing more but a collection of principles

Communication should be stateless : Server should not store any state . If required it should be part of message State should be representational : Internally resource at server can be in one form but it should be able to change it representation. An object referenced by one URI can have different formats available. Different platforms need different formats. Mobile may need JSON whereas desktop may need XML HTTP verbs like GET, POST, PUT, and DELETE must be followed religiously. Resources should be addressable : Every resource on your network should have an specific address(specific URI)

---

I think that the whole question about the concern of the REST architectural style, goes around to understanding, that the author, Roy Fielding, had in his mind to suggest in his dissertation, a set of architectural principles to build architectures based on the hipertext or hipermedia paradigm.

This paradigm, I think, is the central key to understand this important topic.

Behind the style of organizing a client-server application's architecture proposed by Roy Fielding, I think there is a specific idea of a modern client-server application, that consists by a sort of engine to govern application state transition, whose states are potentially extensible to infinite.

In this vision, the Ipertext\Ipermedia is the center of the whole architectural style proposed by Fielding and the key concept that allows this paradigm to work is the "representational (state) transfer".

I think that "representational" refers to the concept about the "transfer", instead of the concept about "state", that is, it is the transfer to be representational (of a representational type), and that is, in my opinion, the main cause of the name "Representational State Transfer".

So, designing a Restful application, it is design first an architecture based on a web of components, each of them comunicates with others in a client-server layered architecture model, sending each of them a representation of its state.

And so, the front-end, the first client of this architecture, transits through its states showing rapresentation of the states sent by the component, or components, that it calls endorsing on a uniform consistent interface and not on a "private" api.

A such type of application, in the mind of the author, is potentially extensible to infinite states, because its states don't depend on a private api, but depend on a univoque identifier system (as URI) shared by all agents in this architecture, on a few some verbs to manage transion of its states and on an agreed shared representational transfer system, or plus.

This transition ends with communication of its representation to the called server component via the verbs that compose the "public" api, which should belong to the stateless communication protocol used by components client-server.

In a such way, this client-server components interaction consists in interchanging (transferring, communicating) representations of components states using a stateless protocol.

And the core concept that allows all these architectures to potentially extend itself to infinite is the representational transfer that endorses their architecture.

---

The meanings of the REPRESENTATIONAL STATE TRANSFER is the REST

RESTful has put DIRECT VERB into server

In actual consideration example, value put into VERB has commonly of HTTP GET and POST

Has SIMPLE protocol much un like the SOAP (has much complex!)

If answer has not satisfaction, please, provide more elaborate of question

REST has much topic of discuss, is topic of many blog and book

---

Imagine a state diagram - the following will do.

https://i.stack.imgur.com/Y9KTb.png

If this were the set of web pages, you would start at Undergraduate landing page for a student. Per the diagram, when you would click on the "Next" link, it will take you to Freshman page - assume the student has graduated. By clicking on "next" multiple times, you get to the last page.

Of course, there could be other transitions like "Home" allowing you to jump to the default page.

The visible state of the website has nothing to with how server implements this association internally - that is the internal states. It may involve multiple databases, servers and what not. A student may graduate and his/her status may have been updated via other methods. The client is not aware of these details - but can always expect to get a coherent visible state (set) for human (or machine) consumption.

Another example: As you are looking at this page, you in a particular identifiable and reproducible "location" in the StackOverFlow web hierarchy.

So, RESTful State deals with navigation.

---

Representations are different forms of a particular resource. For example, the same data might be formatted as a particular media type such as XML or JSON, localized to a particular written language or geographical region, and/or compressed or otherwise encoded for transmission. The underlying resource is the same in each case, but its representation is different.

---