I could not understand what an API Rest is for front and backend communication
I could not understand what an API Rest is for front and backend communication
REST ignores component implementation details and protocol syntax in order to focus on the roles of components, restrictions on their interaction with other components, and their interpretation of meaningful data elements.
It has been officially defined by W3C.
It is often applied to web services by providing APIs to access any service on the web. It fully uses HTTP messages to communicate through what is already defined in the protocol without having to "invent" new protocols specific to that application.
You essentially work with components, connectors, and data.
It uses the HTTP protocol (verbs, accept headers, HTTP status codes, Content-Type) explicitly and representatively to communicate. URIs are used to expose the structure of the service. Uses a common notation for data transfer like XML or JSON. It has no state between these communications, that is, each communication is independent and uniform (standardized) needing to pass all necessary information. It should make it easier to cache content on the client. Must have clear definition of what is part of the client and server. The client does not need to know how the server stores data, for example. So each implementation does not depend on the other and becomes more scalable. It enables layered use also facilitating scalability, reliability and security. It is often created with some form of extensibility.
Example:
link it means that you are asking to delete the ID 1234 product.
Some say that this is wrong and since the emphasis is on resources rather than operations. Should use this:
link (using the DELETE verb) Let's agree that this may work for CRUD, but there are so many variations of what needs to be done that it is not possible to represent everything with HTTP verbs alone. Okay, it's possible to make everything look CRUD, but maybe it requires additional information in the name of formalism.
All this is thought to provide better performance, scalability, simplicity, flexibility, visibility, portability and reliability.
Each defines how you want your API, as opposed to SOAP where everything is officially defined.