REST (REpresentational State Transfer) is an architectural style for developing web services. REST is popular due to its simplicity and the fact that it builds upon existing systems and features of the internet's HTTP in order to achieve its objectives, as opposed to creating new standards, frameworks and technologies.
Advantages of REST
A primary benefit of using REST, both from a client and server's perspective, is REST-based interactions happen using constructs that are familiar to anyone who is accustomed to using the internet's Hypertext Transfer Protocol (HTTP).
An example of this arrangement is REST-based interactions all communicate their status using standard HTTP status codes. So, a 404 means a requested resource wasn't found; a 401 code means the request wasn't authorized; a 200 code means everything is OK; and a 500 means there was an unrecoverable application error on the server.
Similarly, details such as encryption and data transport integrity are solved not by adding new frameworks or technologies, but instead by relying on well-known Secure Sockets Layer (SSL) encryption and Transport Layer Security (TLS). So, the entire REST architecture is built upon concepts with which most developers are already familiar.
REST is also a language-independent architectural style. REST-based applications can be written using any language, be it Java, Kotlin, .NET, AngularJS or JavaScript. As long as a programming language can make web-based requests using HTTP, it is possible for that language to be used to invoke a RESTful API or web service. Similarly, RESTful web services can be written using any language, so developers tasked with implementing such services can choose technologies that work best for their situation.
The other benefit of using REST is its pervasiveness. On the server side, there are a variety of REST-based frameworks for helping developers create RESTful web services, including RESTlet and Apache CXF. From the client side, all of the new JavaScript frameworks, such as JQuery, Node.js, Angular and EmberJS, all have standard libraries built into their APIs that make invoking RESTful web services and consuming the XML- or JSON-based data they return a relatively straightforward endeavor.
Disadvantages of REST
The benefit of REST using HTTP constructs also creates restrictions, however. Many of the limitations of HTTP likewise turn into shortcomings of the REST architectural style. For example, HTTP does not store state-based information between request-response cycles, which means REST-based applications must be stateless and any state management tasks must be performed by the client.
Similarly, since HTTP doesn't have any mechanism to send push notifications from the server to the client, it is difficult to implement any type of services where the server updates the client without the use of client-side polling of the server or some other type of web hook.
From an implementation standpoint, a common problem with REST is the fact that developers disagree with exactly what it means to be REST-based. Some software developers incorrectly consider anything that isn't SOAP-based to be RESTful. Driving this common misconception about REST is the fact that it is an architectural style, so there is no reference implementation or definitive standard that will confirm whether a given design is RESTful. As a result, there is discourse as to whether a given API conforms to REST-based principles.
Alternatives to REST
Alternate technologies for creating SOA-based systems or creating APIs for invoking remote microservices include XML over HTTP (XML-RPC), CORBA, RMI over IIOP and the Simple Object Access Protocol (SOAP).
Each technology has its own set of benefits and drawbacks, but the compelling feature of REST that sets it apart is the fact that, rather than asking a developer to work with a set of custom protocols or to create a special data format for exchanging messages between a client and a server, REST insists the best way to implement a network-based web service is to simply use the basic construct of the network protocol itself, which in the case of the internet is HTTP.
REST vs. SOAP
The two competing styles for implementing web services are REST and SOAP. The fundamental difference between the two is the philosophical approach the two have to remotely invocations.
REST takes a resource-based approach to web-based interactions. With REST, you locate a resource on the server, and you choose to either update that resource, delete it or get some information about it.
With SOAP, the client doesn't choose to interact directly with a resource, but instead calls a service, and that service mitigates access to the various objects and resources behind the scenes.
SOAP has also built a large number of frameworks and APIs on top of HTTP, including the Web Services Description Language (WSDL), which defines the structure of data that gets passed back and forth between the client and the server.
Some problem domains are served well by the ability to stringently define the message format, or can benefit from using various SOAP-related APIs, such as WS-Eventing, WS-Notification and WS-Security. There are times when HTTP cannot provide the level of functionality an application might require, and in these cases, using SOAP is preferable.
REST URIs and URLs
Most people are familiar with the way URLs and URIs work on the web. A RESTful approach to developing applications asserts that requesting information about a resource should be as simple as invoking its URL.
For example, if a client wanted to invoke a web service that listed all of the quizzes available here at TechTarget, the URL to the web service would look something like this:
www.techtarget.com/restfulapi/quizzes
When invoked, the web service might respond with the following JSON string listing all of the available quizzes, one of which is about DevOps:
{ "quizzes" : [ "Java", "DevOps", "IoT"] }
To get the DevOps quiz, the web service might be called using the following URL:
www.techtarget.com/restfulapi/quizzes/DevOps
Invoking this URL would return a JSON string listing all of the questions in the DevOps quiz. To get an individual question from the quiz, the number of the question would be added to the URL. So, to get the third question in the DevOps quiz, the following RESTful URL would be used:
www.techtarget.com/restfulapi/quizzes/DevOps/3
Invoking that URL might return a JSON string such as the following:
{ "Question" : {"query":"What is your DevOps role?", "optionA":"Dev", "optionB":"Ops"} }
As you can see, the REST URLs in this example are structured in a logical and meaningful way that identifies the exact resource being requested.
JSON and XML REST data formats
The example above shows JSON used as the data exchange format for the RESTful interaction. The two most common data exchange formats are JSON and XML, and many RESTful web services can use both formats interchangeably, as long as the client can request the interaction to happen in either XML or JSON.
Note that while JSON and XML are popular data exchange formats, REST itself does not put any restrictions on what the format should be. In fact, some RESTful web services exchange binary data for the sake of efficiency. This is another benefit to working with REST-based web services, as the software architect is given a great deal of freedom in terms of how best to implement a service.
REST and the HTTP methods
The example above only dealt with accessing data.
The default operation of HTTP is GET, which is intended to be used when getting data from the server. However, HTTP defines a number of other methods, including PUT, POST and DELETE.
The REST philosophy asserts that to delete something on the server, you would simply use the URL for the resource and specify the DELETE method of HTTP. For saving data to the server, a URL and the PUT method would be used. For operations that are more involved than simply saving, reading or deleting information, the POST method of HTTP can be used.
History of REST
REST was first coined by computer scientist Roy Fielding in his year-2000 Ph.D. dissertation at the University of California, titled Architectural Styles and the Design of Network-based Software Architectures.
Chapter 5 of the dissertation, "Representational State Transfer (REST)," described Fielding's beliefs about how best to architect distributed hypermedia systems. Fielding noted a number of boundary conditions that describe how REST-based systems should behave. These conditions are referred to as REST constraints, with four of the key constraints described below:
- Use of a uniform interface (UI). As stated earlier, resources in REST-based systems should be uniquely identifiable through a single URL, and only by using the underlying methods of the network protocol, such as DELETE, PUT and GET with HTTP, should it be possible to manipulate a resource.
- Client-server-based. In a REST-based system, there should be a clear delineation between the client and the server. UI and request-generating concerns are the domain of the client. Meanwhile, data access, workload management and security are the domain of the server. This separation allows loose coupling between the client and the server, and each can be developed and enhanced independent of the other.
- Stateless operations. All client-server operations should be stateless, and any state management that is required should happen on the client, not the server.
- RESTful resource caching. The ability to cache resources between client invocations is a priority in order to reduce latency and improve performance. As a result, all resources should allow caching unless an explicit indication is made that it is not possible.
No comments:
Post a Comment