O REST é uma especificação técnica sobre intercomunicação heterogênea para aplicações Web.
A adoção do REST pode levar a uma arquitetura simples, escalável, eficaz, segura e confiável. REST é um protocolo RPC leve construído sobre o protocolo HTTP, sua simplicidade e facilidade na web o torna um alternativa inigualável ao SOAP, uma solução RPC popular há anos. Uma aplicação Web bem estruturada pode ser facilmente construída ao usar o Rest, muitos desenvolvedores criaram com sucesso uma base de API simples e robusta no serviço web Ajax e Restful.
A transferência de estado representacional (REST) ou serviços Web RESTful são uma maneira de fornecer interoperabilidade entre sistemas de computador na Internet. Os serviços da Web compatíveis com REST permitem que os sistemas solicitantes acessem e manipulem representações textuais de recursos da Web usando um conjunto uniforme e predefinido de stateless operations .
O termo transferência de estado representacional foi introduzido e definido em 2000 por Roy Fielding em sua tese de doutorado. Fielding usou REST para projetar HTTP e Uniform Resource Identifiers (URI). Um recurso é um tipo de informação que pode ser acessada, como um aplicativo objeto, um registro de banco de dados, um algoritmo e assim por diante. Cada recurso é identificado por um URI exclusivo (Universal Resource Identifier), REST representam URI na forma de “/user/name”, e operações em métodos HTTP GET, PUT, POST, DELETE, HEADER e OPTIONS, resultando no próximo recurso sendo transferido de volta para o chamador. Uma característica importante do REST é que o lado do servidor mantém sem estado entre várias interações, cada servidor nos clusters pode atender o cliente em cada solicitação.
E quando falamos dos endpoints de APIs Rest Restfuul, ela executa uma operação usando ‘solicitações’ e ‘respostas’. Se as APIs enviarem uma informação de ‘solicitação’ de um aplicativo ou servidor Web, ele receberá uma ‘resposta’. Com APIs REST, um endpoint é uma extremidade de um canal de comunicação. Cada endpoint é um local onde as APIs REST podem acessar os recursos necessários para realizar uma função.
E falando no futuro da API RESTful REST, de acordo com as estatísticas, diz-se que 82% das APIs eram RESTful que são OpenAPI ou Swagger e 21% eram RESTful sem OpenAPI. Há apenas uma pequena queda no uso de APIs REST em APIs públicas. O GraphQL é um concorrente próximo das APIs REST RESTful. Essas APIs sempre permanecerão supremas e não serão afetadas diretamente por outros concorrentes do mercado.
Os verbos HTTP compreendem a maior parte de nossa restrição de “interface uniforme” e nos fornecem a contrapartida de ação para o recurso baseado em substantivos. Os verbos HTTP primários ou mais usados (ou métodos, como são chamados corretamente) são POST, GET, PUT e DELETE. Correspondem a operações de criação, leitura, atualização e exclusão (ou CRUD), respectivamente. Existem vários outros verbos também, mas são utilizados com menos frequência. Desses métodos menos frequentes, OPTIONS e HEAD são usados com mais frequência do que outros.
Abaixo está uma tabela que resume os valores de retorno recomendados dos métodos HTTP primários em combinação com os URIs de recursos:
Tabela 1 - Valores de retorno métodos HTTP
<aside> <img src="/icons/thought-alert_blue.svg" alt="/icons/thought-alert_blue.svg" width="40px" /> Caso tenha interesse em conhecer mais a respeito dos códigos de status das respostas HTTP, você pode visitar o site abaixo:
</aside>
Códigos de status de respostas HTTP - HTTP | MDN
O método HTTP GET é usado para ler (ou recuperar) uma representação de um recurso. No caminho “happy” (ou sem erro), GET retorna uma representação em XML ou JSON e um código de resposta HTTP de 200 (OK). Em um caso de erro, na maioria das vezes ele retorna um 404 (NOT FOUND) ou 400 (BAD REQUEST).
De acordo com o design da especificação HTTP, as solicitações GET (juntamente com HEAD) são usadas apenas para ler dados e não alterá-los. Portanto, quando usados dessa forma, são considerados seguros. Ou seja, eles podem ser chamados sem risco de modificação ou corrupção de dados - chamá-los uma vez tem o mesmo efeito que chamá-los 10 vezes, ou nenhum. Além disso, GET (e HEAD) é idempotente, o que significa que fazer várias requisições idênticas acaba tendo o mesmo resultado de uma única requisição.
Não exponha operações inseguras via GET — ele nunca deve modificar nenhum recurso no servidor.
O verbo POST é usado com mais frequência para criar novos recursos. Em particular, é usado para criar recursos subordinados. Ou seja, subordinado a algum outro recurso (por exemplo, pai). Em outras palavras, ao criar um novo recurso, POST passa o pai e o serviço se encarrega de associar o novo recurso ao pai, atribuir um ID (novo URI de recurso), etc.