Qual \u00e9 a resposta HTTP que sua API REST deve retornar quando o recurso solicitado n\u00e3o existe. <\/p>\n
Por exemplo, considere a seguinte API para buscar um funcion\u00e1rio.<\/p>\n
GET http:\/\/yourservice.com\/api\/v1\/employees\/1<\/a>\r\nResponse Header: 200\r\nBody: {\r\n \"name\":\"Santhosh\", \r\n \"department\":\"Engineering\"\r\n }<\/code><\/pre>\nQuando o empregado solicitado n\u00e3o existe<\/p>\n
GET http:\/\/yourservice.com\/api\/v1\/employees\/<\/a>2\r\nResponse Header: ???\r\nBody: ???<\/code><\/pre>\nExistem tr\u00eas escolhas; 404, 204 e 200<\/strong>. Todos os tr\u00eas parecem adequados para o caso de uso. Vamos examin\u00e1-los detalhadamente com o objetivo de escolher o melhor.<\/p>\nVamos come\u00e7ar com:<\/p>\n
404 n\u00e3o encontrado<\/h3>\n
De acordo com a defini\u00e7\u00e3o do c\u00f3digo de status HTTP\u2026<\/p>\n
\u201cO servidor n\u00e3o encontrou nada que corresponda ao URI de solicita\u00e7\u00e3o.\u00a0Nenhuma indica\u00e7\u00e3o \u00e9 dada se a condi\u00e7\u00e3o \u00e9 tempor\u00e1ria ou permanente.\u00a0O c\u00f3digo de status 410 (Gone) DEVE ser usado se o servidor souber, por meio de algum mecanismo configur\u00e1vel internamente, que um recurso antigo est\u00e1 permanentemente indispon\u00edvel e n\u00e3o possui endere\u00e7o de encaminhamento.\u00a0Esse c\u00f3digo de status \u00e9 comumente usado quando o servidor n\u00e3o deseja revelar exatamente por que a solicita\u00e7\u00e3o foi recusada ou quando nenhuma outra resposta \u00e9 aplic\u00e1vel. \u201d<\/p><\/blockquote>\n
A primeira declara\u00e7\u00e3o faz todo o sentido para o caso.\u00a0No entanto, quando voc\u00ea l\u00ea adiante, fica claro que 404 n\u00e3o \u00e9 a escolha certa por causa das raz\u00f5es a seguir<\/p>\n
\n- O c\u00f3digo \u00e9 usado quando o recurso n\u00e3o est\u00e1 permanentemente dispon\u00edvel, o que n\u00e3o \u00e9 o caso aqui.<\/li>\n
- O servidor n\u00e3o deseja ocultar o motivo exato.<\/li>\n
- H\u00e1 uma terceira raz\u00e3o para n\u00e3o usar o 404;\u00a0a s\u00e9rie 4xx destina-se a sinalizar erros do cliente.\u00a0Mas um recurso restante n\u00e3o dispon\u00edvel n\u00e3o \u00e9 um erro.\u00a0\u00c9 um estado tempor\u00e1rio.<\/li>\n<\/ul>\n
Ambos os candidatos restantes pertencem \u00e0 categoria 2xx.<\/p>\n
“Esta classe de c\u00f3digo de status indica que a solicita\u00e7\u00e3o do cliente foi recebida, entendida e aceita com sucesso.”<\/p><\/blockquote>\n
Sim!\u00a0isso faz sentido para o caso dado.\u00a0Ent\u00e3o, um desses c\u00f3digos de erro deve ser uma escolha melhor em compara\u00e7\u00e3o com 404. Vamos come\u00e7ar com os menos familiares …<\/p>\n
204 Nenhum conte\u00fado<\/strong><\/h3>\nDe acordo com a defini\u00e7\u00e3o do c\u00f3digo de status HTTP\u2026<\/p>\n
O servidor cumpriu a solicita\u00e7\u00e3o, mas n\u00e3o precisa retornar um corpo de entidade e pode querer retornar meta informa\u00e7\u00f5es atualizadas.\u00a0A resposta pode incluir meta informa\u00e7\u00f5es novas ou atualizadas na forma de entidade-cabe\u00e7alhos, que se presentes devem ser associados com a variante solicitada.<\/p><\/blockquote>\n
Se o cliente for um agente do usu\u00e1rio, N\u00c3O DEVE alterar sua vis\u00e3o do documento daquela que fez com que a solicita\u00e7\u00e3o fosse enviada.\u00a0Essa resposta destina-se principalmente a permitir que a entrada de a\u00e7\u00f5es ocorra sem causar uma altera\u00e7\u00e3o na visualiza\u00e7\u00e3o do documento ativo do agente do usu\u00e1rio, embora quaisquer meta-informa\u00e7\u00f5es novas ou atualizadas DEVEM ser aplicadas ao documento atualmente na visualiza\u00e7\u00e3o ativa do agente do usu\u00e1rio.<\/strong><\/p><\/blockquote>\nA resposta 204 N\u00c3O DEVE<\/strong> incluir um corpo de mensagem e, portanto, \u00e9 sempre terminada pela primeira linha vazia ap\u00f3s os campos de cabe\u00e7alho.<\/p><\/blockquote>\n204 parece o candidato certo, porque a sua forma resumida \u00e9 “sem conte\u00fado”.\u00a0No entanto, quando voc\u00ea estuda a defini\u00e7\u00e3o, fica evidente, a partir da quarta declara\u00e7\u00e3o (texto em negrito), que 204 \u00e9 ideal quando uma a\u00e7\u00e3o ocorre no servidor.\u00a0ou seja, POST, PUT ou DELETE<\/strong>;\u00a0Mas esse n\u00e3o \u00e9 o caso quando o cliente invoca uma solicita\u00e7\u00e3o GET<\/strong>.<\/p>\nFicamos com o mais comumente usado 200 OK<\/p>\n
200 OK {com corpo vazio}<\/h3>\n
Conforme a defini\u00e7\u00e3o do c\u00f3digo de status HTTP<\/p>\n
O pedido foi bem sucedido.\u00a0As informa\u00e7\u00f5es retornadas com a resposta dependem do m\u00e9todo usado na solicita\u00e7\u00e3o, por exemplo:<\/p><\/blockquote>\n
GET uma entidade correspondente ao recurso solicitado \u00e9 enviada na resposta;\u00a0\u2026<\/p><\/blockquote>\n
Quando o servidor retorna 200 com um corpo vazio, ele pode ser interpretado como \u201ca solicita\u00e7\u00e3o \u00e9 processada com sucesso, mas o recurso est\u00e1 vazio\u201d. Embora n\u00e3o haja viola\u00e7\u00e3o dos padr\u00f5es HTTP, parece um pouco hacky<\/a>. No entanto, considerando as outras op\u00e7\u00f5es, esta \u00e9 uma op\u00e7\u00e3o muito melhor por causa dos seguintes motivos.<\/p>\n\n- \u00c9 consistente com o comportamento geral do servidor.<\/li>\n
- O c\u00f3digo do cliente n\u00e3o precisa manipular outro c\u00f3digo de resposta HTTP.<\/li>\n<\/ul>\n
Conclus\u00e3o<\/h3>\n
Quando uma solicita\u00e7\u00e3o da API REST GET n\u00e3o tem conte\u00fado, 200 com corpo vazio \u00e9 a melhor op\u00e7\u00e3o de resposta.<\/p>\n
GET http:\/\/yourservice.com\/api\/v1\/employees\/<\/a>2\r\nResponse Header: 200\r\nBody: {}<\/code><\/pre>\nMaterial de Apoio:
\nhttps:\/\/www.w3.org\/Protocols\/rfc2616\/rfc2616-sec6.html#sec6.1.1<\/a>
\nhttps:\/\/restfulapi.net\/http-status-codes\/<\/a><\/p>\n","protected":false},"excerpt":{"rendered":"Qual \u00e9 a resposta HTTP que sua API REST deve retornar quando o recurso solicitado n\u00e3o existe.<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_exactmetrics_skip_tracking":false,"_exactmetrics_sitenote_active":false,"_exactmetrics_sitenote_note":"","_exactmetrics_sitenote_category":0,"_jetpack_memberships_contains_paid_content":false,"footnotes":""},"categories":[170,95,20],"tags":[259],"class_list":["post-13741","post","type-post","status-publish","format-standard","hentry","category-arquitetura","category-design-patterns","category-dicas","tag-api"],"jetpack_featured_media_url":"","jetpack_sharing_enabled":true,"_links":{"self":[{"href":"https:\/\/gianfratti.com\/index.php\/wp-json\/wp\/v2\/posts\/13741","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/gianfratti.com\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/gianfratti.com\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/gianfratti.com\/index.php\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/gianfratti.com\/index.php\/wp-json\/wp\/v2\/comments?post=13741"}],"version-history":[{"count":5,"href":"https:\/\/gianfratti.com\/index.php\/wp-json\/wp\/v2\/posts\/13741\/revisions"}],"predecessor-version":[{"id":13747,"href":"https:\/\/gianfratti.com\/index.php\/wp-json\/wp\/v2\/posts\/13741\/revisions\/13747"}],"wp:attachment":[{"href":"https:\/\/gianfratti.com\/index.php\/wp-json\/wp\/v2\/media?parent=13741"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/gianfratti.com\/index.php\/wp-json\/wp\/v2\/categories?post=13741"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/gianfratti.com\/index.php\/wp-json\/wp\/v2\/tags?post=13741"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}