Rest Estrutura e Arquitetura

A estrutura que o Rest (Representational State Transfer) usa é do HTTP 1.1 onde o acesso a informação fica mais rápido e leve. Onde posso liberar o conteúdo a partir de qualquer estrutura, sendo ela XML, JSON, Texto puro, entre outros.

Com isso o REST herdou alguns códigos de mensagem para retorno da informação, segue:

• Código 200 indica que sua requisição foi um sucesso, todo sucesso no código fonte deve-se retornar HTTP 200.
• Código 201 ele deve ser a resposta de inserção de algum dado feito pelo Controller ou Collection.
• Código 202 enviado para o Controller que obteve uma conexão assíncrona.
• Código 204 a resposta irá mostra que intencionalmente o corpo de código foi deixado em branco.
• Código 301 indica que um novo URI foi inserido para o cliente.
• Código 303 resposta é enviado para retornar dados que considera opcional.
• Código 304 resposta enviada para preservar o consumo da banda.
• Código 307 indica que uma URI foi gerado temporariamente para o cliente consumir seu recurso.
• Código 400 indica que o caminho acessado está com erro.
• Código 401 indica erro que o cliente não está autorizado para o envio da requisição.
• Código 402 envia para a requisição negar o recurso para o cliente.
• Código 404 a requisição pode estar fora ou não existe.
• Código 405 interage com o cliente a partir do momento que o cliente envia um método HTTP não suportado.
• Código 406 erro retornado quando o cliente tenta solicitar tipo de dados não suportado.
• Código 409 indica que o cliente tentou violar um estado do objeto.
• Código 412 mostra para o cliente que uma de suas condições requisitadas não foi cumprida.
• Código 415 erro mostrado quando o cliente envia dados de uma mídia não suportados.
• Código 500 retorna para o cliente dizendo que possuí erro grave.

Com isso o REST determina alguns pontos de aceitação em sua camada, que são (GET, POST, DELETE, PUT, HEAD, TRACE, OPTIONS e CONNECT).

Mas para os desenvolvedores os mais usados são GET, POST, PUT e DELETE. Segue a especificação dos mais usados:

• GET: Para recuperar os dados.
• PUT: Alterar um dado.
• POST: Para criar um dado.
• DELETE: Para deletar um dado.

A arquitetura REST ela funciona para liberar uma URI, definida para o serviço de execução, e trafega os dados a partir da requisição solicitada, além de trabalhar totalmente em MVC.

Segue uma imagem:

Conforme a imagem acima posso ter qualquer camada de layout em qualquer framework FRONT-END que acesso via REST os dados solicitados.

É como se eu tivesse um Serviço Web disponível a qualquer momento, segue exemplo:

REST hoje ele pode facilitar o uso e a separação das camadas, assim podendo ter uma camada indiferente da linguagem, posso usar Python, Java, PHP, entre outras linguagens que utiliza o protocolo HTTP 1.1.

Além de executar uma arquitetura baseada em Serviço, ter um reaproveitamento de código fonte, reutilização dos métodos e menos trabalho a partir de um tempo de execução da arquitetura.

Rest tem alguns padrões a serem seguidos:

Designer de caminhos:

Cada segmento de caminho URI, separados por barras representa uma oportunidade de Designer.

Atribuindo valores significativos para cada segmento de caminha ajuda a comunicar de forma clara a estrutura do projeto.

Regra que deve ser usado um substantivo singular para nomes dos documentos. Exemplo:

http://localhost:8080/funcionarios/arquitetos-software/paulo.

Regra um substantivo no plural deve ser usado para nomes de coleções. Exemplo:

http://localhost:8080/jogos/dungeons-dragons/jogadores.

Regra um substantivo no plural deve-se armazenar nomes no URI para identificação do recurso.

Exemplo: http://localhost:8080/musicas/david-guetta/playlists errado séria http://localhost:8080/musicas/david-guetta/playlist, pois estou com um recurso que é uma coleção de dados.

Regra de expressão verbal ou verbos deve ser usado como nomes de Controller, neste caso um URI

deve identificar o recurso passado para a Controller e ser nomeado para indicar sua ação. Exemplo:

http://localhost:8080/estudante/paulo/registrar.

Regra os segmentos de variáveis podem ser substituído com base em identidades e valores, alguns

caminhos podem ser estáticos e outros segmentos de URI são variável o que significa que são

automaticamente preenchidos e fornece a singularidade do URI. E uma substituição de um URI pode ser feito a partir da API REST escolhida e assim que o cliente executar a substituição, pode ser repassado um identificador numérico ou alfanumérico. Exemplo: http://localhost:8080/escola-municipal/turma-7/aluno/12 ou http://localhost:8080/escola-municipal/turma-7/aluno/1ab2.

Regra de nomes de funções CRUD não deve ser usado em um URI, a utilização da semântica do URI deve ser apenas para identificar recursos e valores variável. Exemplo:

http:localhost:8080/ctis/ms/colaboradores/123 dessa forma está correto, errado será a utilização dessa forma http://localhost:8080/ctis/ms/atualizar-colaboradores/123, além de ser fora do contexto HTTP, está mostrando qual funcionalidade do CRUD irá executar deixando frágil seu código.

Métodos de Requisição:

A RFC2616 Request-Line trabalha com o URI e os métodos específicos do HTTP 1.1 e cada método HTTP tem a semântica especifica e definida para o seu funcionamento e contexto.

Regra os métodos GET e POST não devem ser usados fora de seu contexto, assim foge de toda a

intenção da mensagem e máscara o proposito do método HTTP.

Regra GET deve ser utilizada para recuperar dados de uma consulta qualquer, apenas isso.

Regra HEAD deve ser utilizado para recuperar os cabeçalhos de uma requisição/resposta, o HEAD

recebe os dados como o GET mas sem um corpo e este recurso é usado para recuperar os metadados de uma requisição.

Regra o PUT deve ser usado para atualizar ou inserir um dado a partir de um objeto jogado na URI de chamada.

Regra o PUT deve ser utilizado para modificar/atualizar um dado mutável.

Regra POST deve ser utilizada para criar um novo item na coleção.

Regra POST deve ser usada para invocar controladores orientados por função.

Regra DELETE deve ser usado para deletar/apagar um registro a partir de uma requisição feita pelo

usuário.

Regra OPTIONS deve ser usada para recuperar metadados que gerou uma iteração e está disponível

no cabeçalho de conversação.

Conclusão:

REST facilita e trás alguns benefícios para nós desenvolvedores, mas antes devemos pensar em como implementar e como podemos reaproveitar o trabalho executado. A estrutura e a arquitetura tem que ser bem definida. Espero ter ajudado.

Referências:

• http://www.rfc-editor.org/rfc/rfc2068.txt - Acessado 17/12/2014 á 02/01/2015
• http://www.rfc-base.org/txt/rfc-2119.txt - Acessado 17/12/2014 á 02/01/2015
• http://www.rfc-base.org/txt/rfc-3986.txt - Acessado 06/01/2015
• http://www.rfc-base.org/txt/rfc-2616.txt - Acessado 07/01/2015