REST (REpresentational State Transfer) – TechTarget

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 Hypertext Transfer Protocol (HTTP) in order to achieve its objectives, as opposed to creating new standards, frameworks and technologies.
There are several advantages to using REST. They are as follows:
Disadvantages of REST are as follows:
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).
In general, every technology has benefits and drawbacks. However, a unique feature of REST is that instead of requiring that developers work with custom protocols for client-server message exchanges, REST insists that the best way to implement network-based web services is to use the basic construct of the network protocol itself, which in terms of the internet is HTTP.
This is an important component, as REST is not intended to apply just to the internet; rather, its principles are intended to apply to all protocols, including WebDav and FTP.

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 remote 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 mediates 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.
Most programmers 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 state should be as simple as invoking its URL.
For example, if a client wanted to invoke a web service that listed all 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 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 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.
The example above employed JSON 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 format.
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.
The example above only dealt with accessing data.
The default operation of HTTP is GET, which is intended to be used when retrieving data from the server. However, HTTP defines several 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.
To accommodate the growing popularity of REST-based systems, there are several frameworks to help developers create RESTful web services.
Some of the more popular open source frameworks for creating Java-based, RESTful web services include Apache CXF, Jersey, Restlet, Apache Wink, Spring Data and JBoss’ RESTEasy.
The general approach of each of these frameworks is to help developers build RESTful web services using semantics that are familiar to Java developers, including Java Platform (Enterprise Edition), the Servlet API and annotations, while at the same time offering built-in classes and methods that make it easier to conform to the basic tenets of REST.
Given the near ubiquity of REST APIs and the explosive number of devices on the internet of things (IoT), it seems to be a perfect pairing. Compact formats based on JSON, EXI and CBOR (Concise Binary Object Representation), a JSON offshoot, are used and RESTful APIs are likewise compact.
In an IoT scheme, devices work in a client-server relationship. In that relationship, devices can act as clients, servers or both. Devices can act as a client and initiate contact with a directory, such as the CoRE Resource Directory, or another device. Devices can also act in the capacity of an origin server or resource, such as to serve as a sensor, serving temperatures or other status indicators.
Yet, as noted above, all client-server operations using REST should be stateless, and any state management that is required should happen on the client, not the server. That means all messages must contain all the information to process it, independent from previous messages.
Two things have helped REST become popular with IoT developers. First, REST is already pervasive, well-understood and replicable. Second, because the data requested from resources in IoT tends to be simple, such as a sensor’s current reading, and static, such as a manufacturer’s device description, REST, which utilizes the internet’s HTTP, is a natural fit.
REST was first coined by computer scientist Roy Fielding in his year 2000 Ph.D. dissertation at the University of California, Irvine, 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:
Buying mobile app development tools
Chaos engineering tool options include the original (Chaos Monkey), open source projects like Chaos Toolkit and Chaos Mesh and …
Docker Desktop is now part of all Docker subscriptions, including a new Business tier with added security, but enterprise users …
Any Agile team that wants its team’s culture to be squarely centered on improving software quality, should consider the following…
While it’s inevitable that certain cloud-hosted applications will share resources, the vulnerabilities these connections expose …
A poorly executed cloud resource tagging strategy, or having no strategy at all, can cost a bundle down the road. Build the best …
Follow along to set up Google Cloud Operations’ Monitoring and Logging services, try Google’s Monitoring Query Language and …
Are you prepared for a cloud-native migration? This quiz contrasts the microservice vs. monolithic approaches to software …
Do you need to loop through a collection of objects and need to decide between a Java Iterator or an Enumeration? Here’s why you …
Iterators in Java are a simple mechanism to help developers avoid runtime exceptions. Let’s explore the difference between …
All Rights Reserved, Copyright 2019 – 2021, TechTarget

Privacy Policy
Cookie Preferences
Do Not Sell My Personal Info

source