The Tool Desk
Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →Uma API é uma interface que permite a componentes de software trocar dados ou solicitar operações. REST é um estilo arquitetural que pode orientar o projeto dessa interface; HTTP é um protocolo usado com frequência para transportar as solicitações e respostas na Web. Os três termos descrevem coisas diferentes.
O que é uma API
API é a sigla de interface de programação de aplicações. Ela define regras para que um componente de software solicite dados ou operações a outro e interprete o resultado. Em uma API HTTP, essa comunicação normalmente acontece por mensagens de solicitação e resposta.
![Computer Networking Bible: [3 in 1] The Complete Crash Course to Effectively Design, Implement and Manage Networks. Including Sections on Security, Performance and Scalability](https://m.media-amazon.com/images/I/41H4YJnxKgL._SL160_.jpg)
As an Amazon Associate I earn from qualifying purchases.
Uma analogia: imagine um balcão de atendimento com regras publicadas. O cliente faz um pedido conforme essas regras e recebe um resultado com informações sobre o que ocorreu. A API corresponde às regras e formas de interação; HTTP pode ser o protocolo usado para enviar as mensagens. É apenas uma analogia: não é necessário haver uma pessoa, um único servidor físico ou uma sequência rígida de passos.
Como REST e HTTP se relacionam
REST é um estilo arquitetural, não um protocolo nem um sinônimo de API. Roy Thomas Fielding apresentou suas restrições na dissertação Architectural Styles and the Design of Network-based Software Architectures, publicada pela University of California, Irvine, em 2000 (dissertação de Fielding). REST não está limitado a um protocolo específico, embora HTTP seja o protocolo Web mais associado a APIs que seguem esse estilo.
#1 Best Overall
HTTP, por sua vez, é um protocolo com semântica padronizada para as mensagens. A RFC 9110, publicada pelo IETF em junho de 2022, define essa semântica e explica que o método da solicitação é a principal fonte de seu significado (RFC 9110: HTTP Semantics).
Em REST, a interação gira em torno de recursos identificados e de representações transferidas entre componentes. Um recurso é uma abstração identificável, não necessariamente um arquivo ou objeto físico; seus valores podem mudar com o tempo. Uma URI identifica o recurso, mas não é o próprio dado: uma representação enviada pode variar conforme o estado ou a solicitação.
REST também envolve restrições arquiteturais, entre elas cliente-servidor, ausência de estado entre solicitações, sistema em camadas e uma interface uniforme. Entre os princípios dessa interface estão identificar recursos, manipulá-los por meio de representações, usar mensagens autodescritivas e permitir que a hipermídia oriente o estado da aplicação. Por isso, um caminho legível como /usuarios/42, por si só, não prova que uma API cumpra o estilo REST.
O que acontece em uma solicitação de API
- O cliente identifica um recurso. Por exemplo, um cliente hipotético de loja pode querer obter o produto identificado por
/produtos/42. - O cliente envia uma solicitação conforme a interface. Ela contém um método HTTP e pode incluir cabeçalhos e conteúdo, conforme o contrato da API.
- O serviço interpreta a solicitação. O método, o recurso-alvo e os demais dados ajudam a determinar a operação solicitada. O serviço pode não implementar ou não permitir determinado método para aquele recurso.
- O serviço responde. A resposta inclui um código de status e pode trazer uma representação. O status comunica o resultado; o conteúdo fornece dados quando aplicável.
- O cliente decide o que fazer em seguida. Pode apresentar a informação, atualizar sua própria interface ou realizar outra solicitação conforme as respostas e regras da API.
Esse fluxo é um modelo explicativo, não o relato de um teste contra um serviço real. A URL identifica um recurso; ela não determina, sozinha, o conteúdo que será devolvido.
O que os principais métodos HTTP pedem
Os métodos carregam semântica padronizada, mas a aplicação ainda pode recusar um método ou restringi-lo para um recurso. O conteúdo e o status da resposta também influenciam o resultado observado.
| Método | Finalidade geral | Seguro? | Idempotente? |
|---|---|---|---|
| GET | Solicita uma representação atual do recurso. | Sim | Sim |
| HEAD | Solicita uma resposta equivalente à de GET, mas sem o conteúdo da resposta. | Sim | Sim |
| POST | Solicita processamento específico do recurso; a operação exata depende do contrato da API. | Não | Não definido genericamente como idempotente |
| PUT | Solicita substituir as representações atuais do recurso pelas informações fornecidas. | Não | Sim |
| DELETE | Solicita remover a associação entre o recurso-alvo e sua funcionalidade atual. | Não | Sim |
| OPTIONS | Solicita informações sobre as opções de comunicação disponíveis para o recurso. | Sim | Sim |
| TRACE | Solicita um teste de loop-back da mensagem ao longo do caminho até o servidor. | Sim | Sim |
A RFC 9110 define GET, HEAD, OPTIONS e TRACE como métodos seguros; GET, HEAD, OPTIONS, TRACE, PUT e DELETE como idempotentes. A tabela resume a semântica do protocolo, não garante que uma aplicação implemente todos os métodos.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Seguro e idempotente não significam a mesma coisa
Seguro: não solicitar uma mudança de estado
Um método seguro indica que, pela semântica definida, o cliente não está solicitando uma mudança de estado no servidor. Isso não garante ausência de efeitos incidentais: um servidor ainda pode, por exemplo, registrar um acesso.
Recommended Free Tools
Idempotente: repetir mantém o efeito pretendido
Uma solicitação idempotente tem o mesmo efeito pretendido no servidor quando repetida que teria se fosse executada uma vez. As respostas ou registros podem ser diferentes entre tentativas. PUT e DELETE são idempotentes, mas não seguros: podem solicitar mudanças de estado.
Best Value
- Used Book in Good Condition
Essa diferença importa quando uma conexão falha e o cliente considera tentar novamente. A RFC não define POST genericamente como idempotente; portanto, não se deve presumir que repetir uma solicitação POST seja inofensivo. O cliente precisa considerar o contrato da API e saber se a operação pode ter sido processada antes de a conexão falhar.
API, REST, HTTP, JSON e URL: diferenças rápidas
- API: a interface e suas regras para interação entre componentes.
- REST: um estilo arquitetural que pode orientar o desenho de uma API.
- HTTP: um protocolo que define a semântica das mensagens de solicitação e resposta.
- JSON: um formato possível para representar dados; não é requisito definidor de REST, e nem toda API REST precisa usar JSON.
- URL ou URI: um identificador do recurso, não o recurso nem necessariamente uma representação fixa de seus dados.
Assim, REST e HTTP não são tecnologias concorrentes: um descreve restrições de arquitetura e o outro define um protocolo. E chamar uma interface de “API REST” exige mais do que usar HTTP ou organizar rotas com nomes de recursos.
O que uma API bem documentada deve esclarecer
- Quais recursos podem ser identificados e como fazê-lo.
- Quais métodos são aceitos para cada recurso e o que cada solicitação pretende fazer.
- Quais formatos e dados a solicitação pode conter e quais formatos podem aparecer na resposta.
- Quais códigos de status e resultados o cliente pode receber.
- Quais operações podem ser repetidas com segurança operacional, conforme a semântica HTTP e o contrato específico da API.
Usar REST ou HTTP não torna uma API automaticamente segura. A segurança depende de decisões e controles concretos, não apenas do nome do estilo ou do protocolo.
Free tools Windows power users keep installed
One-click scans. No signup required.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
