What is REST?
REST stands for Representational State Transfer. REST as described in MSDN, “is an architectural style that can be used to build software in which clients (user agents) can make requests of services (endpoints)”. REST is one way to implement a client-server architectural style. A service that uses the architectural style of REST is generally referred to as a RESTful service or endpoint.
RESTful endpoint Building Blocks
1. Resources(What resources would the service Serve/Offer)
2. URI(Identifiers used to represent the resources)
3. HTTP Verbs (What parts of the uniform interface (HTTP verbs) are each URI going to support, like Get/Post etc.)
I’ll develop a hypothetical system that will make use of these blocks in the next article, let us consider the theoretical aspects of the REST in this post.
Why REST?
As explained above, REST internally implements a Client/Server model that can be easily achieved by using SOAP with ASMX or WCF. Just for the discussion sake RPC is also one of the options that can be used. Forget about these big terms, as a web developer all of us have been implementing Client architecture long before the REST was introduced, then why to use REST?
The question can be answered in all possible ways, but let’s consider only the following two points.
a) REST offers some significant features and benefits over RPC
b) Microsoft is moving many of its own implementations away from RPC technologies (such as SOAP) and toward REST.
Very absurd answer though, these are the main reasons why as a developer we should consider using REST.
Rest of the post is dedicated to the features and benefits that REST offers.
Caching: Resources returned in response to a GET request, using RESTful service can be cached in many different ways.
Conditional GET: It offers a way in which a client can check with the service if his version of the data is still the current version. It is an optional implementation detail a RESTful endpoint can implement that makes sure that the client always gets the latest resource.
Scale-Out: REST encourages each resource to contain all of the states necessary to process a particular request. RESTful services are much easier to scale out when they fulfill this constraint and can be stateless.
Reliability: The other two main HTTP verbs (besides GET) used as part of the uniform interface are PUT and DELETE. PUT is most often used when a user agent wants to modify a resource, and DELETE is used for remove the resource. These two can be used on a particular resource more than once. This provides reliability when building reliable distributed systems in which errors, network failures, or latency might cause code to execute multiple times.
Interoperability: REST only requires an HTTP library to be available for most operations (an XML library, of course, is often useful as well), and it is certainly more interoperable than any RCP technology (including SOAP).
The above features are a glimpse of what RESTful services offer, there are many more features that can be explored using any of the modern day search engines.
This post explored the REST and the part-2 will describe WCF Services in relation to REST implementation. In that post I’ll develop an app that will show the RESTful service implementation.
Hope this was helpful.
Till next we connect……..
Happy Learning.
REST stands for Representational State Transfer. REST as described in MSDN, “is an architectural style that can be used to build software in which clients (user agents) can make requests of services (endpoints)”. REST is one way to implement a client-server architectural style. A service that uses the architectural style of REST is generally referred to as a RESTful service or endpoint.
RESTful endpoint Building Blocks
1. Resources(What resources would the service Serve/Offer)
2. URI(Identifiers used to represent the resources)
3. HTTP Verbs (What parts of the uniform interface (HTTP verbs) are each URI going to support, like Get/Post etc.)
I’ll develop a hypothetical system that will make use of these blocks in the next article, let us consider the theoretical aspects of the REST in this post.
Why REST?
As explained above, REST internally implements a Client/Server model that can be easily achieved by using SOAP with ASMX or WCF. Just for the discussion sake RPC is also one of the options that can be used. Forget about these big terms, as a web developer all of us have been implementing Client architecture long before the REST was introduced, then why to use REST?
The question can be answered in all possible ways, but let’s consider only the following two points.
a) REST offers some significant features and benefits over RPC
b) Microsoft is moving many of its own implementations away from RPC technologies (such as SOAP) and toward REST.
Very absurd answer though, these are the main reasons why as a developer we should consider using REST.
Rest of the post is dedicated to the features and benefits that REST offers.
Caching: Resources returned in response to a GET request, using RESTful service can be cached in many different ways.
Conditional GET: It offers a way in which a client can check with the service if his version of the data is still the current version. It is an optional implementation detail a RESTful endpoint can implement that makes sure that the client always gets the latest resource.
Scale-Out: REST encourages each resource to contain all of the states necessary to process a particular request. RESTful services are much easier to scale out when they fulfill this constraint and can be stateless.
Reliability: The other two main HTTP verbs (besides GET) used as part of the uniform interface are PUT and DELETE. PUT is most often used when a user agent wants to modify a resource, and DELETE is used for remove the resource. These two can be used on a particular resource more than once. This provides reliability when building reliable distributed systems in which errors, network failures, or latency might cause code to execute multiple times.
Interoperability: REST only requires an HTTP library to be available for most operations (an XML library, of course, is often useful as well), and it is certainly more interoperable than any RCP technology (including SOAP).
The above features are a glimpse of what RESTful services offer, there are many more features that can be explored using any of the modern day search engines.
This post explored the REST and the part-2 will describe WCF Services in relation to REST implementation. In that post I’ll develop an app that will show the RESTful service implementation.
Hope this was helpful.
Till next we connect……..
Happy Learning.
Comments
Post a Comment