1. Addressability
Addressability is the idea that every object and resource in your system is reachable through a unique identifier. In the REST world, addressability is managed through the use of URIs. Using a unique URI to identify each of your services makes each of your resources linkable. Service references can be embedded in documents.
2. The Uniform, Constrained Interface
The idea behind it is that you stick to the finite set of operations of the application protocol you’re distributing your services upon. This means that you don’t have an “action” parameter in your URI and use only the methods of HTTP for your web services. HTTP has a small, fixed set of operational methods. Each method has a specific purpose and meaning (i.e. GET, PUT, DELETE, POST, HEAD, OPTIONS).
3. Representation-Oriented
Each service is addressable through a specific URI and representations are exchanged between the client and service. With a GET operation, you are receiving a representation of the current state of that resource. A PUT or POST passes a representation of the resource to the server so that the underlying resource’s state can change. In a RESTful system, the complexity of the client-server interaction is within the representations being passed back and forth. These representations could be XML, JSON, YAML, or really any format you can come up with. With HTTP, the representation is the message body of your request or response.
4. Communicate Statelessly
In REST, stateless means that there is no client session data stored on the server. The server only records and manages the state of the resources it exposes. If there needs to be session-specific data, it should be held and maintained by the client and transferred to the server with each request as needed. A service layer that does not have to maintain client sessions is a lot easier to scale, as it has to do a lot fewer expensive replications in a clustered environment. It’s a lot easier to scale up, because all you have to do is add machines.
Addressability is the idea that every object and resource in your system is reachable through a unique identifier. In the REST world, addressability is managed through the use of URIs. Using a unique URI to identify each of your services makes each of your resources linkable. Service references can be embedded in documents.
2. The Uniform, Constrained Interface
The idea behind it is that you stick to the finite set of operations of the application protocol you’re distributing your services upon. This means that you don’t have an “action” parameter in your URI and use only the methods of HTTP for your web services. HTTP has a small, fixed set of operational methods. Each method has a specific purpose and meaning (i.e. GET, PUT, DELETE, POST, HEAD, OPTIONS).
3. Representation-Oriented
Each service is addressable through a specific URI and representations are exchanged between the client and service. With a GET operation, you are receiving a representation of the current state of that resource. A PUT or POST passes a representation of the resource to the server so that the underlying resource’s state can change. In a RESTful system, the complexity of the client-server interaction is within the representations being passed back and forth. These representations could be XML, JSON, YAML, or really any format you can come up with. With HTTP, the representation is the message body of your request or response.
4. Communicate Statelessly
In REST, stateless means that there is no client session data stored on the server. The server only records and manages the state of the resources it exposes. If there needs to be session-specific data, it should be held and maintained by the client and transferred to the server with each request as needed. A service layer that does not have to maintain client sessions is a lot easier to scale, as it has to do a lot fewer expensive replications in a clustered environment. It’s a lot easier to scale up, because all you have to do is add machines.