REST

REST stands for Representational State
Transfer and was looked at in the dissertation
by Roy Thomas Fielding.
Some of the most important aspects of the
REST environment are uniquely addressable
resources, their different characteristics
and formats, a uniform and easy - to - follow programming interface, and the facilitation of a highly
scalable environment.
Implemented today, REST mainly entails the use of technologies which are already well established
in practice on the Web and which have been used to outline the advantages of REST. HTTP or
HTTPS, for example, may be used as the transfer protocol. URLs including query strings are
used to address resources, and the representation formats supported range from HTML and XML
to JSON and ATOM, as well as to sound and video fi les. The simple and intuitive programming
interface previously mentioned is achieved by using HTTP verbs and status codes.
If, for example, you point your browser at the URL http://p2p.wrox.com/content/blogs ,
status code 200 is returned and your browser displays the returned HTML in the form of a
web site. In keeping with normal web practices, the following page also contains links to other
resources and topics:
In the URL above you can also see how intuitively these URLs are structured. Or use the following
URL to receive an RSS feed:
In contrast to SOA with SOAP, REST is not concerned with the defi nition of messages and the
design of methods; central components are resources and actions which can affect those resources.
The actions which affect resources are mainly CRUD (Create, Read, Update, and Delete) methods.
What should be done with a resource is determined by means of an HTTP verb, and the success of
the action is ascertained by querying the HTTP status code.
In the following example, a GET at http://localhost:1234/CarPool shows all the cars in the
fl eet in the form of an XML document. Status code 200 indicates success.
URL: http://localhost:1234/CarPool
Verb: GET
Status-Code: 200
Response-Body:
< Cars xmlns="http://schemas.datacontract.org/2004/07/Wrox"
xmlsn:i="http://www.w3.org/2001/XMLSchemainstance"
> < Car > < Make > Dodge < /Make > < Name > Dakota < /Name > < Seats > 8 < /Seats > < Type > Pickup
Truck < /Type > < /Car > < Car > < Make > Audi < /Make > < Name > TT < /Name > < Seats > 2 < /Seats > < Type > Sport
Car < /Type > < /Car > < Car > < Make > Seat < /Make > < Name > Leon < /Name > < Seats > 5 < /Seats > < Type > Sport
Car < /Type > < /Car > < /Cars >
In the following example, a GET at http://localhost:1234/CarPool/TT shows the Audi TT in the
form of an XML document. Status code 200 indicates success. Status code 404, for example, would
mean not found.
http://localhost:1234/CarPool/TT
Verb: GET
Status-Code: 200
Response-Body:
< Car xmlns="http://schemas.datacontract.org/2004/07/Wrox"
xmlsn:i="http://www.w3.org/2001/XMLSchemainstance"
> < Make > Audi < /Make > < Name > TT < /Name > < Seats > 2 < /Seats > < Type > Sport
Car < /Type > < /Car >
In the following example, a GET at http://localhost:1234/CarPool/TT?format=json shows the
Audi TT in the form of a JSON document. Status code 200 indicates success. Status code 404, for
example, would mean not found.
URL: http://localhost:1234/CarPool/TT?format=json
Verb: GET
Status-Code: 200 (OK)
Response-Body:
{"Make":"Audi","Name":"TT","Seats":2,"Type":"Sport Car"}
In the following example, a PUT at http://localhost:1234/CarPool/Leon with the requisite
XML data in the request body would mean that the car is to be added to the car pool. Status code201 means created. As a result of the POST action, the added object is normally returned, along with
any further details or links to other objects.
URL: http://localhost:1234/CarPool/Leon
Verb: PUT
Request-Body:
< Car xmlns="http://schemas.datacontract.org/2004/07/Wrox"
xmlns:i="http://www.w3.org/2001/XMLSchema-instance" >
< Make > Seat < /Make > < Name > Leon < /Name > < Seats > 4 < /Seats > < Type > Sport
Car < /Type > < /Car >
Status-Code: 201 (Created)
Response-Body:
< Car xmlns="http://schemas.datacontract.org/2004/07/Wrox"
xmlsn:i="http://www.w3.org/2001/XMLSchemainstance"
> < Make > Seat < /Make > < Name > Leon < /Name > < Seats > 4 < /Seats > < Type > Sport
Car < /Type > < /Car >
Apart from GET and PUT , which have already been seen, the verbs most commonly used also include
DELETE and POST .
GET is used exclusively to retrieve data and, therefore, the result can also be buffered without any
concerns. It also offers a major advantage over SOAP messages in which the actual call cannot be
identifi ed straight away as a reading call. Therefore, they are also diffi cult to buffer.
DELETE is used for deleting resources. It should be called up as often as you wish without any
concerns about side effects. When http://localhost:1234/CarPool/Leon is called up for the fi rst
time, for example, the Leon is deleted. The next time the same URL is called up, the resource is no
longer available and can, therefore, not be deleted either.
PUT is used to add or change a resource if you can defi ne the URL yourself. For example, a PUT at
http://localhost:1234/CarPool/Leon along with corresponding details in the request body
means that this resource is added anew with the URL used. If you assign a PUT to this URL with
other values in the request body, it would lead to an update in the resource.
POST is an exception in certain regards. First of all, POST is frequently misused as DELETE and
PUT , because the use of DELETE and PUT is either not permitted or technically impossible from the
browser ’ s perspective. Secondly, POST is used to add new resources to a container without having
control of the URL created. Thus, for example, a POST to http://localhost:1234/CarPool
with corresponding details in the body would mean that a new car is being added to the carpool.
However, in this case the POST call would have to return the URL of the newly created resource.
In any event, the REST is stateless. Therefore, whenever a call is made, all the requisite values are
either transferred in the address of the resource or as additional parameters. This behavior also
means that REST applications are generally much easier to scale because there is no need to be
concerned about which server to send the query to in a load - balanced environment.
REST and WCF
WCF not only provides a platform for SOAP messages, it is also a means of offering RESTful
services.
The essential components that allow you to create a REST application can be found in System.
ServiceModel.Web.dll . The most important elements of a REST application include the [WebGet]
and [WebInvoke] attributes and the new binding webHttpBinding in connection with the webHttp
endpoint behavior.
If you use [WebGet] or [WebInvoke] , the [OperationContract] attribute is
optional.
Should you wish to create a RESTful solution from your SOAP - based solution, theoretically you
would simply have to change the binding to webHttpBinding and confi gure the endpoint with the
webHttp behavior.
This binding has the following effect: If you send a SOAP message to an endpoint in a classical SOA
environment, the content of the message will normally be checked fi rst. The correct operation will
be called up depending on the content of the message.
In REST, however, the method which is called up is dependent on the URL and on the verb used.
This altered dispatch behavior is made possible by the binding webHttpBinding and the webHttp
endpoint behavior. Furthermore, the WebHttpBehavior class or the endpoint behavior also enables
you to choose from two different serialization formats:
POX (Plain old XML) uses XML alone without the SOAP overhead.
JSON (JavaScript Object Notation) is a very compact and effi cient format, primarily in connection
with JavaScript.