Have you ever heard the term REST thrown around in discussions about web development, but weren't quite sure what it means?
REST, short for Representational State Transfer, is a design pattern that defines the way a client-side application (such as a website or mobile app) communicates with a web service using HTTP protocols. This allows for the creation, removal, update, and deletion of data (also known as CRUD operations).
The term REST was introduced by Roy Fielding in his doctoral dissertation in 2000.
But what exactly is a RESTful service, and how does it work? A RESTful service is a web service that implements the REST design pattern and exposes CRUD operations at specific endpoints. Each endpoint is responsible for managing a specific collection of data.
For example, let's say you are searching for something online on a service like YouTube. You type in your search term "funny cat videos" and hit enter. What you get back is a list of videos that match your search term. This is made possible by an API, or application programming interface, which allows the client (in this case, the web browser) to communicate with the web service (in this case, YouTube).
A RESTful API works in a similar way. You send a request to the web service with some identifying information (such as your search term), and it gives you back a list of results. The main difference is the rules that developers must follow when creating their API. For example, in a RESTful API, you should be able to retrieve data (a resource) by calling a specific URL. This call should return a response, which can then be used by the client.
Now that we have a basic understanding of REST and RESTful services, let's delve a little deeper into the design and implementation of these APIs.
REST API design
When developing a RESTful service, the frontend and backend are typically implemented independently of each other. This practice, known as separation of concerns, allows for the frontend (the client-side) to be updated and changed without affecting the backend (the web service). Similarly, the backend can be updated and changed without affecting the frontend, as long as the endpoints remain unchanged.
This separation of concerns improves the flexibility and scalability of the application as a whole, as both the frontend and backend are independent of each other. It also allows for code reuse, an important concept in object-oriented programming and the Don't Repeat Yourself (DRY) principle.
In order to facilitate large-scale designs, the coupling between the client and the web service should be as loose as possible. This is achieved by exposing defined resources and entities, while hiding the implementation details. Clients can only access these resources using the URLs made available.
When creating a RESTful API, a base URL (such as api.example.com) is made available, and all the different HTTP methods operate off of that. These methods can be used to perform CRUD operations on the data managed by the API.
Stateless REST APIs
A REST API is considered stateless when each call to the API can be made independently of one another. This means that all the necessary data to complete a call is passed along with the call itself. By storing identifiable information about the state of the client-side, we can reduce memory requirements and improve the scalability and reliability of the REST API. Instead of relying on the server state to create objects, which can sometimes fail, each call to the REST API should include all the necessary data, such as access tokens and IDs.
RESTful web APIs are typically based on HTTP methods that can be accessed through specific URLs. These URLs may be encoded and require some form of authentication or token verification for access. Data is usually transferred between the URLs using JSON or XML, and the payload or response is also returned in this format.
What is an HTTP protocol?
HTTP (Hypertext Transfer Protocol) is a protocol for transmitting data over the internet. It is the foundation of the modern web and is used to communicate between web clients and servers.
HTTP works by sending messages, called requests, from a client (such as a web browser) to a server. The server then sends back a response to the client. The request and response messages contain a set of headers, which provide additional information about the request or response, such as the type and size of the data being transmitted. The body of the message contains the actual data being transmitted.
There are several different types of HTTP requests that can be made, including GET, POST, PUT, DELETE, and HEAD. Each type of request has a specific purpose and is used to perform different actions on the server.
For example, a GET request is used to retrieve data from the server, while a POST request is used to send data to the server to be processed or stored. A PUT request is used to update existing data on the server, and a DELETE request is used to delete data from the server.
HTTP is a stateless protocol, which means that each request is independent of any other request and does not depend on the current state of the server. This allows for scalability and flexibility, as the server does not need to store any information about previous requests.
Common HTTP status codes
1xxs: Informational responses, the server is still processing the request.
2xxs: Success, the request was successfully completed
3xxs: Redirected, the request was received and has redirected you to another address.
4xxs: Client errors, for example, 404 - page not found. The request is made, but the page trying to load is not valid
5xxs: Server error, request failed. A valid request was made but failed to be completed at the server.
REST vs SOAP
SOAP (Simple Object Access Protocol) and REST are both web service architectures that are used to create APIs for communication between systems. SOAP is a formal and strict protocol that uses XML for message encoding, while REST is a more flexible and lightweight protocol that can use any data format and relies on HTTP methods to perform actions on resources. The choice between SOAP and REST will depend on the specific needs and requirements of the API being developed. If you want to delve deeper into the differences between these two then be sure to read my article on the topic.
Until then, I hope you found this article helpful. Happy coding šāāļø.
