REST

Hello Again, this week I’m going to be talking about REST. I do mean the software engineering principle, and not the thing a person does when they get tired. Representational state transfer or REST is architectural style in engineering that was made to define constraints for web services. Set up to make a standard for communication between computer systems. A web service that follows these constraints are considered RESTful.

First defined by Roy Fielding in 2000, REST is a format a set of instructions to follow for creating a web service, which is a service offered by one electronic device to another. If a web service is REST compliant, any request sent to the web service allows access to a textual representation of the requested resource that the client can manipulate via a set of predefined operations. The web service sends the information and does not retain any information from the client and the client uses the information as they see fit without saving the actual representation. The response from the web service is usually formatted in XML, HTML, or JSON. The response can provide hypertext links, or routes the client can take to get to other resources.

In order for a service to be considered RESTful it has to follow the following constraints. Support separation of concerns between a client and server. Separating data storage and user interface improves the port portability of the client. It must be stateless, meaning that the server side cannot store context from the client. The system must be layered meaning the client has no indication that it is talking directly to the server or through intermediary services. The interface must be uniform. This means that any manipulation is handled through representations of resources sent by the service. It also means that the service should send information on how to handle the received data.

As most people get confused rest is just an architecture for your code and nothing specific. As long as a service follows the guidelines it ca be considered RESTful.