Rest — Além do trivial.
Vamos falar de Rest um pouco ? Bora lá!
Todo mundo já ouviu falar de Rest e de seus verbos, mas eu tenho uma pergunta para você.
Dada uma requisição para recuperar um recurso, qual verbo usar ? Se você disse GET… Acerto “MISERAVI” ! Mas e se o recurso não for encontrado, qual o protocolo HTTP que deve ser retornado ? hehe e agora meu nobre, o obvio parece tentador não é?! Deixe me sugerir 3 opções:
HTTP_OK_200 — IiiHuuu, teve sucesso na requisição é 200!
HTTP_NO_CONTENT_204 — IZI(easy), teve sucesso mas não temos dado a retornar.
HTTP_NOT_FOUND_404 — Mas é claro, como poderia errar isso… Não foi encontrado ué!
Então, depois dessa ajudinha qual a sua resposta? Há, temos mais de 1 resposta correta! Eu sei, você ta dizendo agora que já sabia disso… Eu sei, eu sei… você é fera!!
Mas vamos lá, deixa eu ir ao ponto!
A resposta correta é depende! Se estamos falando de uma requisição, precisamos saber qual a URL requerida e isso fará toda a diferença. Como assim? Simples, imagine duas requisições, localhost:8080/api/user/1 e localhost:8080/api/user?id=1. No primeiro caso se trata de um path parameter, utiliza-lo torna a URL mais amigável e tem suas finalidades(cabe um artigo sobre path ou query parameter) mas caso o recurso não seja encontrado deve retornar 404(Recurso não foi encontrado). No segundo caso temos uma URL menos amigável com uso de query parameter que não deve retornar 404 e sim 204(Sucesso na requisição mas sem dados para serem retornados). Sucess ou 200 nunca deve ser retornado pois é uma premissa que se tratando do verbo GET, ele deve retornar uma entidade correspondente ao recurso requisitado, o que não é o nosso caso. O que ganhamos com isso? Muito, mas só de cara, nossas APIs já podem ser tratadas considerando o protocolo HTTP que retornamos para nossos consumidores sem que eles quebrem porquê não implementamos o protocolo HTTP corretamente e nunca é demais lembrar que REST é uma arquitetura por cima do protocolo HTTP.
Quer saber mais sobre os os protocolos HTTP, da uma olhada aqui: https://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html
É isso, vlw e fui!
Published By
Originally published at https://www.linkedin.com.
