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