Hoje eu encontrei uma lista REST incrível do que fazer e não fazer do StackOverFlow:
Princípios gerais para um bom design de URI:
- Não use parâmetros de consulta para alterar o estado
- Não use caminhos com maiúsculas e minúsculas, se puder; letras minúsculas é melhor
- Não use extensões específicas de implementação em seus URIs (.php, .py, .pl, etc.)
- Não caia no RPC com seus URIs
- Limite o seu espaço de URI o máximo possível
- Mantenha os segmentos do caminho curtos
- Prefira / resource ou / resource /; crie redirecionamentos 301 daquele que você não usa
- Use parâmetros de consulta para sub-seleção de um recurso; ou seja, paginação, consultas de pesquisa
- Remova coisas do URI que deveriam estar em um cabeçalho HTTP ou corpo (Observação: eu não disse “Design de URI RESTful”; URIs são essencialmente opacos em REST.)
Princípios gerais para a escolha do método HTTP:
- Nunca use GET para alterar o estado; esta é uma ótima maneira de fazer com que o Googlebot estrague o seu dia
- Não use PUT a menos que esteja atualizando um recurso inteiro
- Não use PUT, a menos que você também possa fazer um GET no mesmo URI legitimamente
- Não use o POST para recuperar informações de longa duração ou que possam ser razoáveis para armazenar em cache
- Não execute uma operação que não seja idempotente com PUT
- Use GET o máximo possível
- Use POST em vez de PUT em caso de dúvida
- Use o POST sempre que precisar fazer algo parecido com o RPC
- Use PUT para classes de recursos que são maiores ou hierárquicas
- Use DELETE em vez de POST para remover recursos
- Use GET para coisas como cálculos, a menos que sua entrada seja grande, caso em que use POST
Princípios gerais de design de serviço da web com HTTP:
- Não coloque metadados no corpo de uma resposta que deveria estar em um cabeçalho
- Não coloque metadados em um recurso separado, a menos que sua inclusão crie uma sobrecarga significativa
- Use o código de status apropriado
201 Criado após criar um recurso; o recurso deve existir no momento em que a resposta é enviada
202 Aceito após realizar uma operação com sucesso ou criar um recurso de forma assíncrona
400 Bad Request quando alguém faz uma operação em dados que são claramente falsos; para seu aplicativo, isso pode ser um erro de validação; geralmente reserva
500 para exceções não capturadas
401 Não autorizado quando alguém acessa sua API sem fornecer um cabeçalho de autorização necessário ou quando as credenciais na autorização são inválidas; não use esse código de resposta se não estiver esperando credenciais por meio de um cabeçalho de autorização.
403 Proibido quando alguém acessa sua API de uma forma que possa ser maliciosa ou se não estiver autorizado
405 Método não permitido quando alguém usa POST quando deveria ter usado PUT, etc
413 Solicitação de entidade muito grande quando alguém tenta enviar um arquivo inaceitavelmente grande
418 Eu sou um bule quando tento fazer café com um bule
Use cabeçalhos de cache sempre que puder
Os cabeçalhos de ETag são bons quando você pode facilmente reduzir um recurso a um valor de hash
A última modificação deve indicar a você que manter um registro de data e hora de quando os recursos são atualizados é uma boa ideia
Cache-Control e Expires devem receber valores razoáveis
Faça tudo o que puder para respeitar os cabeçalhos de cache em uma solicitação (If-None-Modified, If-Modified-Since)
* Use redirecionamentos quando fizerem sentido, mas eles devem ser raros para um serviço da web
FONTE: http://stackoverflow.com/questions/1619152/how-to-create-rest-urls-without-verbs/1619677#1619677