Published by Sascha Neumeier
Last updated on March 03, 2022
•
6 minute read
Do you know exactly what REST is, what a RESTful API does, and how it all differs from SOAP (and other messaging protocols)? Yes? Excellent, then you don't need to read any further and you can go enjoy our brand-new PRTG Desktop. If not, lean back and read on. The topic is very abstract, but I want to try to describe everything as understandably as possible. Let's go...
REST – A Relaxing Definition
When unfamiliar terms appear on the horizon, it's worth taking a quick look at Wikipedia to get a first overview. For REST it reads in Wiki jargon as follows:
Representational State Transfer (REST) is an architectural style that defines a set of constraints to be used for creating web services. Web Services that conform to the REST architectural style, or RESTful web services, provide interoperability between computer systems on the Internet. REST-compliant web services allow the requesting systems to access and manipulate textual representations of web resources by using a uniform and predefined set of stateless operations.
REST just stands for “REpresentational State Transfer” and is one way for two applications to communicate with one another through the web protocol. REST does not include an additional messaging layer and focuses on design rules for creating stateless services. The REST architecture was developed to solve the complexity of older technologies, such as SOAP.
REST can be used to view or modify certain resources on a server without performing any server-side operation. REST consists of two main components: client and server.
The client requests a resource from the server and sends a response, providing there are no errors. The response itself is a representation of the resource present on the server. For example, it could be a JSON, PDF, XML or something like that. This explains why the service is representational.
REST is stateless. All the information that the server needs to give the answer is provided with the request itself. Usually requests are made by using a HTTP connection and in the form of a URI (Uniform Resource Identifier) combined with a common HTTP method.
| GET | Retrieve resource representation/information only |
| POST | Create new subordinate resources |
| PUT | Update existing resource |
| DELETE | Delete resources |
| PATCH | Make partial update on a resource |
For security reasons, for the POST, PUT and DELETE methods, authentication is required. This is usually handled by an API key.
REST vs. REST API vs. RESTful API vs. RESTful Web service
It seems more difficult than it really is. When people talk about a REST API (= RESTful API), they mean a programming interface based on REST. A set of one or more logically related REST Web services (= RESTful Web services) is an example of a RESTful API.
REST vs. SOAP
You already learned that REST is an architectural style. SOAP (Simple Object Access Protocol), on the other hand, describes a XML-based messaging protocol specification. There are considerable differences between the two.
SOAP uses WSDL (Web Services Description Language) for communication between client and server, REST just uses XML or JSON to send and receive messages. While SOAP invokes services by calling an RPC method, REST simply makes requests via a URI. SOAP doesn't return a human readable result; a REST result is readable due to the usage of file formats like XML, JSON, PDF or similar. Whilst REST only uses HTTP, SOAP also uses other protocols like SMTP or FTP.
In return, REST has a better overall performance in comparison to SOAP. Basically, REST is just HTTP without any overhead. So, if your service is using HTTP anyway, you can't get much leaner than REST. By encoding your representations directly in JSON instead of in XML, you save some extra bytes!
Phew, it's not that easy to make such an abstract topic reasonably understandable. I hope I was able to shed some light on the terminology of REST.
If you want to read more about technical topics like this, leave us a comment.
You there!
