Resources, once identified, can be returned by the server in a different format, such as JSON, XML, HTML, PNG,  SVG, and so on. These formats are a representation of the identified resources, and the client will understand the list of possible well-defined formats or media types (also called Multipurpose Internet Mail Extension (MIME)) from the headers.

The resource's representation is manipulated or processed by clients. The application needs to support more than one representation of the same resource and the same URI; in other words, the same exact resource is represented by different clients in different ways.

Let's take an example; a document might be represented as JSON to an automated program, but as HTML to a web browser. The purpose of these representations is to provide a way to interact with the resource, and so the clients can indicate the intended representations they wish to receive.

The preceding conceptual distinction allows the resource to be represented in different ways without changing its identifiers. It is possible with the HTTP header (Accept) getting passed to the server by the clients in each request. The resources are updated or added by sending representations from the client by the RESTful application. The following diagram is a sample representation format, captured for a sample request from my Postman tool:

So, the decoupling of the resource's representation from the URI is one of the crucial aspects of REST.

The following list shows various content-type representation formats (as headers) that one can use in the request or response:

• Text/HTML, text/CSS, text/JavaScript
• Application/XML, application/JSON, application/x-www-form-urlencoded 
• Image (SVG, JPG, PNG, and so on)