REST, Representational State Transfer, is a type of web development architecture that is fully supported by the HTTP standard.
REST allows us to create services and applications that can be used by any device or client that understands HTTP, so it is incredibly simpler and more conventional than other alternatives that have been used in the last ten years as SOAP and XML-RPC.
REST was defined in 2000 by Roy Fielding, co-author also of the HTTP specification. We could consider REST as a framework to build web applications respecting HTTP. Therefore REST is the most natural and standard type of architecture to create APIs for Internet-oriented services.
There are three levels of quality when applying REST in the development of a web application. These levels are: correct use of URLs, the correct use of HTTP and Implement Hypermedia.
In addition to these three rules, you should never save status on the server, all the information that is required to show the requested information should be in the query by the client.
By not saving state, REST gives us a lot of play, since we can scale better without having to worry about issues such as storage of session variables and even, we can play with different technologies to serve certain parts or resources of the same API.
Correct use of URLs
When we develop a web or a web application, the URLs allow us to access each of the pages, sections or documents of the website. Each page, information in a section, file, when we talk about REST, we name them as resources.
The resource is therefore the information that we want to access or that we want to modify or delete, regardless of its format.
The URL, Uniform Resource Locator, is a type of URI, Uniform Resource Identifier, which, in addition to allowing to uniquely identify the resource, allows us to locate it in order to access it or share its location.
Knowing HTTP well is not optional for a web developer who cares about his work. To develop REST APIs, the key aspects that must be mastered and clear are: HTTP methods, status codes, acceptance of content types.
One of the most frequent errors when building an API is usually to reinvent the wheel by creating our own tools instead of using those that have already been created, thought out and tested. The most reinvented wheel in the development of APIs are the error codes and status codes.
When we perform an operation, it is necessary to know if this operation has been carried out successfully or in the opposite case, why it has failed. If you are dealing with this business and you still have concerns, stoplight is there to help you.