The ideas and constraints of Representational State Transfer (REST), as initiated by Roy T. Fielding, provide an architectural style of web services that in many ways suit the needs of enterprise applications better. The ideas lead to systems that are coupled more loosely with interfaces that are accessed from various clients in a uniform and straightforward way.

The REST constraint of a uniform interface requires the resources to be identified in requests using the URI in web-based systems. The resources represent our domain entities; for example, users or articles which are individually identified by URLs of the enterprise application. That said, the URLs no longer represent RPC methods, but actual domain entities. These representations are modified in a uniform way, in HTTP using the HTTP methods such as GET, POST, DELETE, PATCH, or PUT. The entities may be represented in different formats that are requested by the client, such as XML or JSON. If supported by the server, clients are free to choose whether they access the specific user in its XML or JSON representation.

Another aspect of the uniform interface constraint is to make use of Hypermedia as the engine of the application state. Hypermedia means linking resources that are related together using hyperlinks. REST resources that are transferred to the client can include links to other resources with semantic link relations. If some user includes information about their manager, that information can be serialized using a link to the resource of the second user, the manager.

The following shows an example for a book representation with Hypermedia links included in a JSON response:

{
     "name": "Java",
     "author": "Duke",
     "isbn": "123-2-34-456789-0",
     "_links": {
         "self": "https://api.example.com/books/12345",
         "author": "https://api.example.com/authors/2345",
         "related-books": "https://api.example.com/books/12345/related"
    }
}

In websites designed for humans, these links are one of the main aspects. In a Hypermedia API, these links are used by the REST clients to navigate through the API. The concept of discoverability decreases coupling and increases evolvability of the systems involved. If this concept is fully embraced, clients only need to know an entry point of the API and discover the available resources using semantic link relations, such as related-books. They will follow the known relations using the provided URLs.

In most REST APIs, it's not sufficient for clients to only follow links and fetch resource representation using the HTTP GET method. Information is exchanged using HTTP methods that change state such as POST or PUT and request bodies which contain the payload. Hypermedia supports these so-called actions as well, using Hypermedia controls. Actions describe not only the target URL, but also the HTTP method and required information to send.

The following demonstrates a more sophisticated Hypermedia example using the concept of actions. This example shows the Siren content type and is meant to give you an idea of potential contents of Hypermedia responses:

{
    "class": [ "book" ],
    "properties": {
        "isbn": "123-2-34-456789-0",
        "name": "Java",
        "author": "Duke",
        "availability": "IN_STOCK",
        "price": 29.99
    }
    "actions": [
        {
            "name": "add-to-cart",
            "title": "Add Book to cart",
            "method": "POST",
            "href": "http://api.example.com/shopping-cart",
            "type": "application/json",
            "fields": [
                { "name": "isbn", "type": "text" },
                { "name": "quantity", "type": "number" }
            ]
        }
    ],
    "links": [
        { "rel": [ "self" ], "href": "http://api.example.com/books/1234" }
    ]
}

This is one example of a content type that enables Hypermedia controls. At the time of writing this book, none of the hypermedia-enabled content type such as Siren, HAL, or JSON-LD has emerged as a standard or de facto standard yet. However, this Siren content type should sufficiently communicate the concepts of links and actions.

Using Hypermedia decouples the client from the server. First of all, the responsibility of URLs solely reside on the server side. Clients cannot make any assumption how the URLs are created; for example, that the book resource resides under /books/1234, which is constructed from the path /books/ plus the book ID. We have seen many of these assumption that duplicate URL logic into the clients in real-world projects.

The next aspect that is decoupled is how state is changed on the server. For example, the instruction that clients need to POST a JSON content type to /shopping-cart with a certain JSON structure is no longer baked into the client, but retrieved dynamically. The client will only refer to the Hypermedia action using its relation or name, here add-to-cart, and the information provided in the action. By using this approach, the client only needs to know the business meaning of the add-to-cart action and the origin of the required ISBN and quantity field. This is certainly client logic. The field values could be retrieved from the resource representation itself or from a client process. For example, the quantity of books could be presented as a drop-down field in the UI.

Another potential of using Hypermedia is to decouple business logic from the client. By using links and actions to direct the client to available resources, the information contained in the available links and actions is used to implicitly tell clients which use cases are possible with the current state of the system. For example, assuming that only books which have a certain availability can be added to the shopping cart. Clients that implement this behavior, that is, only showing an add-to-cart button for these situations, need to be aware of this logic. The client functionality then will check whether the book availability meets the criteria, and so on. Technically, this business logic should reside on the server-side only. By dynamically providing links and actions to available resources, the server dictates which functionality is possible under the current state. The add-to-cart action would then only be included if the book can actually be added to the cart. The client logic therefore is simplified to checking whether links and actions with known relations or names, respectively, are included. Therefore, the client only displays an active add-to-cart button if the corresponding action is provided in the response.

Together with the advent of Java EE, the REST architectural style gained more and more attention. While most web services out there don't implement all of the constraints that the REST architectural style defines, especially Hypermedia, they are mostly considered as REST services.

For more information about REST constraints, I refer you to the dissertation of Roy T. Fielding's Architectural Styles and the Design of Network-based Software Architectures.