Rest Service and HTTP
Representational State Transfer (REST) defines a set of architectural principles by which you can design Web services that focus on a system's resources, including how resource
states are addressed and transferred over HTTP by a wide range of clients written in different languages. REST is a style of architecture based on a set of principles
that describe how networked resources are defined and addressed.
- Uniform Interface - Resources are manipulated via CRUD (create, read, update, delete) operations. CRUD operations are managed via PUT, GET, POST, and DELETE request methods.
- Stateless - In REST the state is contained within the request itself, or as part of the URI, query-string parameters, body or in the headers. After processing the request, the state may be communicated back via the headers, status or response body.
- Cacheable - Responses from the web service to its clients are explicitly labeled as cacheable or non-cacheable. This way, the service, the consumer, or one of the intermediary middleware components can cache the response for reuse in later requests.
- Client Server - This is a key constraint, as it based on separations of concerns. The client/server requirement ensures that a distributed environment exists. It requires the client, that sends requests and a server component that receives the requests. After processing the request, the server may return a response to the client.
- Layered System - A client should may not be able to tell whether it is connected directly to the end server, or to an intermediary along the way. Intermediary servers may add security policies, or improve scalability.
- Code On Demand - This is an optional constraint. It allows a client to have logic locally via the ability to download and execute code from a remote server.
- Give every thing its own ID
- Link things together (HATEOAS)
- Use standard HTTP methods
- Resources can have mulitple representations
- Communicate statelessly
- Support Caching
HTTP is the protocol that allows for sending documents back and forth on the web. A protocol is a set of rules that determines which messages can be exchanged, and which
messages are appropriate replies to others. In HTTP, there are two different roles: server and client. In general, the client always initiates the conversation; the server
replies. HTTP is text based; that is, messages are essentially bits of text, although the message body can also contain other media. Text usage makes it easy to monitor
an HTTP exchange.
HTTP messages are made of a header and a body. The body can often remain empty; it contains data that you want to transmit over the network, in order to use it according to the instructions in the header. The header contains metadata, such as encoding information; but, in the case of a request, it also contains the important HTTP methods. In the REST style, you will find that header data is often more significant than the body.