em "SOAP Opera", do Hacktoon (o XKCD brasileiro!) e em acontecimentos do dia-a-dia. REST é um estilo de arquitetura de APIs, não um padrão. Proposto por em 2000 por Roy Fielding em sua tese de doutorado. Mas não vamos ser formais!
Isolamento de implementação Um monte de buzzword que a gente adora (escalabilidade, simplicidade, portabilidade, bla bla bla) Uma resposta em json, xml ou algum outro formato estruturado E o que às vezes é deixado de lado: URLs padronizadas Uso dos verbos do HTTP nas requisições Uso dos códigos do HTTP nas respostas
que vão nas respostas: 1XX: informacionais 2XX: sucesso 200 OK, 201 created, 202 accepted, 204 no content... 3XX: redirecionamento 4XX: erro do cliente 400 bad request, 401 unauthorized, 403 forbidden, 404 not found... 5XX: erro no servidor 500 server error, 503 unavailable, 504 timeout... Objetivo é informar o resultado do que foi pedido
{"error": "not found"}, status=200 Muitas APIs não utilizam corretamente o status Muitas APIs não tratam corretamente o método Exemplo do terror: Cliente faz requisição GET para /api/v1/books/create/ Servidor responde {"status": "ok"} status=200
faz requisição POST em /api/v1/books/ Servidor responde {"status": "created"}, status=201 Cliente faz requisição GET em /api/v1/books/ Servidor responde {"books": [<lista de livros>]}, status=200 Em caso de URL não encontrada, o status é o famoso 404 Em caso de processamento assíncrono, podemos usar o status 202 (accepted) Resumindo: usar os verbos e os status para sinalizar intenções e resultados
GET /api/v1/books/ POST /api/v1/books/ GET /api/v1/books/1234/ PUT /api/v1/books/1234/ PATCH /api/v1/books/1234/ DELETE /api/v1/books/1234/ Objetivo Lista os livros Cria um livro Exibe um livro Cria um livro Edita um livro Apaga um livro