Qual é a maneira correta de fazer o REST?


36

Atualmente, todo mundo faz SOA , mesmo que alguns não entendam realmente o que é isso. Então eles fazem errado. Usando isso como analogia, sei o que é REST (ou pelo menos acho que faço) e quero fazer parte dele. Mas eu quero fazer certo.

Então, minha pergunta é qual é a maneira correta de fazer o REST?


1
Stack Overflow 'descanso' tag wiki parece ser o mais próximo que ele chegue ao recurso canônico no contexto da rede de pilha Câmbio
mosquito

17
Eu apenas fecho meus olhos por um tempo ... talvez faça um passeio de bicicleta e depois me deitei.
Edward Strange

O REST não está basicamente apenas usando um URL como mydomain.com/accounts e um verbo HTTP para chamar uma operação? Onde o verbo indica se você deseja obter, criar, atualizar ou excluir dados? Quando penso em REST, é nisso que penso.
The Muffin Man

2
@ Nick, essa é a interpretação mais comum, a 'coisa real' é muito mais difícil de entender, e (até onde eu sei) muito mais difícil de encontrar realmente implementada em qualquer lugar ... (veja a resposta de Wilk)
Benjol

3
@Nick, seu entendimento não é REST, é RPC sobre HTTP .

Respostas:


30

Bem, existem várias maneiras de aprender a criar um aplicativo Web RESTful e não, não existe um caminho certo exclusivo. RESTful não é um padrão, mas usa um conjunto de padrões (HTTP, URI, Mime Type, ...).

Comece com isso: Como expliquei o REST para minha esposa

Em seguida, continue com o seguinte: Livro de Receitas de Serviços da Web RESTful

E então faça todo o seu esforço para desenvolver aplicativos da Web, porque a melhor maneira de aprender é fazer experimentos e você pode aprender muito com seus erros;)

Não se preocupe se seus primeiros aplicativos da Web não forem completamente RESTful: você encontrará o caminho para fazê-lo!

Então, citando Obi-Wan Kenobi, "que a força esteja com você!" ;)

EDITAR

Ok, deixe-me ser mais específico. Você quer fazer algum aplicativo web RESTful, não é? Bem, como eu disse, existem muitas maneiras de fazer isso, mas essa é a principal diretriz.

Definição

REST (Representational State Transfer) é o estilo de uma arquitetura de software para sistemas distribuídos (como WWW). Não é um padrão, mas usa um conjunto de padrões: HTTP, AJAX, HTML, URI, Mime Type, etc. Estamos falando sobre representação de um recurso, não sobre um recurso em si. Retirado de 'Como expliquei o REST para minha esposa':

Esposa : Uma página da web é um recurso?

Ryan : Mais ou menos . Uma página da web é uma representação de um recurso. Recursos são apenas conceitos.

Restrições da arquitetura

  • Cliente-servidor : cliente e servidor são separados pela interface uniforme (descrita abaixo).
  • Sem estado : a comunicação servidor-cliente é feita sem salvar um determinado estado do cliente no servidor.
  • Cachable : o cliente pode ter um cache de respostas de solicitações já feitas.
  • Sistema em camadas : o cliente não sabe se está diretamente conectado a um servidor final ou se a comunicação é feita através de intermediários.

Interface uniforme

  • Identificação dos recursos : cada recurso deve ser identificado por um URI.
  • Protocolo : para acessar o cliente e o servidor de comunicação, um protocolo deve ser feito antes. Cada solicitação pode ter o Tipo MIME correto (aplicativo / xml, texto / html, aplicativo / rdf + xml, etc.), os cabeçalhos corretos e o método HTTP correto (consulte a descrição CRUD abaixo).

CRUD

Ok, vimos que, para identificar recursos, podemos usar o URI, mas precisamos de mais alguma coisa para as ações (adicionar, modificar, excluir etc.): uma grande bem-vinda ao CRUD (Criar, Ler, Atualizar e Excluir).

  • Crie { HTTP: POST } { SQL: INSERT } => crie um novo recurso
  • Leia { HTTP: GET } { SQL: SELECT } => obtenha um recurso
  • Atualizar { HTTP: PUT } { SQL: UPDATE } => modificar um recurso
  • Excluir { HTTP: DELETE } { SQL: DELETE } => excluir um recurso

Agora, com relação a PUT e DELETE, alguns problemas técnicos podem aparecer (você os obterá no formato HTML): geralmente os desenvolvedores ignoram esse problema usando POST para cada solicitação 'PUT' e 'DELETE'. Oficialmente, você deve usar PUT e DELETE. A propósito, faça o que quiser. Minha experiência me leva a usar POST e GET sempre.

--- A próxima parte deve ser usada, mas não é um vínculo do REST: trata-se de dados vinculados ---

URI

URI abstrato dos detalhes técnicos! Diga adeus ao URI da seguinte maneira:

http://www.example.com/index.php?query=search&id=9823&date=08272012

Redesenhe o URI! Pegue o link acima e altere-o da seguinte maneira:

http://www.example.com/search/2012/08/27/9823

Está muito melhor, não é? Isso poderia ser feito por:

Outra coisa: use URI diferente para representar recursos diferentes:

Preste atenção : about.html e about.rdf não são arquivos! Eles podem ser o resultado de uma transformação XSLT!

Negociação de conteúdo

Se você chegou a esse ponto, parabéns! Provavelmente, você está pronto para obter conceitos mais abstratos porque estamos inserindo os detalhes técnicos da Web Semântica;) Bem, quando seu cliente deseja um recurso, ele normalmente faz a seguinte solicitação:

GET http://www.example.com/about
Accept: application/rdf+xml

Mas o servidor não responde com o about.rdf porque possui um URI diferente ( http://www.example.com/about.rdf ). Então, vamos dar uma olhada no padrão 303 ! O servidor retornará isso:

303 See Other
Location: http://www.example.com/about.rdf

E o cliente seguirá o link retornado da seguinte forma:

GET http://www.example.com/about.rdf
Accept: application/rdf+xml

Por fim, o servidor retornará o recurso solicitado:

200 OK
about.rdf

Não se preocupe: seu aplicativo cliente não fará nada disso! O padrão 303 deve ser feito pelo aplicativo do servidor e seu navegador fará o resto;)

Conclusão

Muitas vezes, a teoria está muito longe da prática. Sim, agora você sabe como projetar e desenvolver um aplicativo RESTful, mas a diretriz acima é apenas uma dica. Você encontrará a melhor maneira de criar aplicativos da Web e provavelmente não será o mesmo que a teoria deseja. Não dê a mínima: D!

Bibliografia

Serviços Web RESTful, Sameer Tyagi

APIs REST devem ser baseadas em hipertexto, Roy Thomas Fielding

Serviços da Web RESTful: Noções básicas, Alex Rodriguez

Fluxo de trabalho REST da Webber


1
Você pode adicionar este link , que é o guia mais completo que já encontrei.
Benjol

Eu vi PUT e POST usados ​​com seus significados trocados (em relação à sua resposta): POST -> create, PUT -> update. Alguma idéia de qual significado é mais amplamente usado?
Andres F.

@Andres F .: jcalcote.wordpress.com/2008/10/16/… diz: Create = PUT se você estiver enviando o conteúdo completo do recurso especificado (URL). Create = POST se você estiver enviando um comando ao servidor para criar um subordinado do recurso especificado, usando algum algoritmo do lado do servidor. Update = PUT se você estiver atualizando o conteúdo completo do recurso especificado. Update = POST se você estiver solicitando ao servidor que atualize um ou mais subordinados do recurso especificado.
Wilk

@ Benjol: Eu vou editar com sua sugestão;) Obrigado!
Wilk

1
@ Wilk Algumas coisas a considerar! Provavelmente porque ninguém acertou: P
Andres F.

5

um livro da Bíblia REST ou algo assim ....

Não é necessário livro da Bíblia; Eu tinha as mesmas perguntas exatas e aprendi tudo o que precisava ou queria saber sobre o REST lendo estes três artigos:

  1. Introdução ao HTTP e REST para iniciantes do Net Tuts +
  2. Serviços da Web RESTful: Noções básicas do IBM developerWorks
  3. HTTP RESTful na prática da InfoQ

Mas eu quero fazer certo.

Como você lerá nos artigos acima, a chave é pensar nas partes acessíveis do seu aplicativo como "recursos" que podem ser criados, recuperados, atualizados ou excluídos usando os "verbos" HTTP existentes: GET, PUT, POST , DELETE.

Além disso, saiba a diferença entre PUT e POST e quando usá-los. GET, PUT E DELETE devem ser transações idempotentes, POST não.

Além disso, faça uso adequado dos códigos de status HTTP ao se comunicar novamente com o cliente.

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.