Why you should care about REST

Why you should care about REST

[22]

What is a REST API?

REST stands for Representational State Transfer. It is a lighter weight alternative to SOAP and WSDL XML-based API protocols. Developing a REST API enables us to create a foundation upon which we can build all other applications. As previously mentioned, these applications may be web-based or designed for specific platforms, such as Android or iOS. A REST API also makes it easy to implement other interfaces or applications over time, turning the initial project from a single. application into a powerful platform.

Simply put, it is a way to communicate between your frontend and the database/server. When a request is made via a REST API, it sends a representation of the resource’s current state to the requestor or the endpoint. The state representation can take the form of JSON, XML or HTML. Among these, JSON is the most widely used file format because of its language-independent feature and it can be read by both humans and machines.

What model does REST use?

REST uses a client-server model, where the server is an HTTP server and the client sends HTTP verbs (GET, POST, PUT, DELETE), along with a URL and variable parameters that are URL-encoded. The URL describes the object to act upon and the server replies with a result code and valid JavaScript Object Notation (JSON).

REST-HTTP Methods

HTTP Codes

HTTP, the HyperText Transfer Protocol is the foundation of communication on the web. As a part of the HTTP protocol, error codes are used to indicate various status scenarios during a request-response cycle. The HTTP error codes provide valuable information about the outcome of a request and enable effective error handling.

Imagine a banking API that allows to make fund transfers via a banking application. In a real world scenario, the API should fail if a user tries to transfer more funds to their account. To provide a seamless user experience and avoid potential financial losses, the API must handle such errors gracefully. For errors HTTP defines two ranges: Client errors that start with 4xx and Server errors that start with 5xx. Some of the common HTTP result codes that are often used inside REST APIs are as follows:

1xx Informational Responses

  • 100 - Continue: It states that the server has received the initial part of the request and awaits the remaining portion. It is commonly used for large file uploads or when the request needs to be sent in multiple parts.

2xx Success Responses

  • 200 - OK: The request was successful and the server has returned the requested resource. This is the most common success code.

  • 201 - Created: The request was successful and a new resource was created as a result. It is used with POST.

  • 204 - No Content: It states that the server successfully processed the request but did not return any content. It is often used for requests that require no response body.

  • 400 - Bad Request: It means that perhaps there is a required parameter that’s missing. In this case the server cannot or will not process the request due to something that is perceived to be a client error.

  • 401 - Unauthorized: Defines missing authentication parameters.

  • 402 - Payment Required: This means that the request cannot be processed until the client makes a payment.

  • 403 - Forbidden: You were authenticated but lacking required privileges).

  • 404 - Not Found:

  • 409 - Conflict: It tells that there is a request conflict with the current state of the target resource.

CRUD Operation

The CRUD acronym is often used to describe database operations. CRUD stands for CREATE, READ, UPDATE, and DELETE. These operations map very nicely to the HTTP verbs, as follows: POST: A client wants to insert or create an object. GET: A client wants to read an object. PUT: A client wants to update an object. DELETE: A client wants to delete an object.