Quais são os melhores / mais comuns verbos e ações para url RESTful?

86

Estou tentando encontrar algumas informações sobre as melhores e mais comuns ações de url RESTful.

por exemplo, qual url você usa para exibir os detalhes de um item, para editar o item, atualizar, etc.

/question/show/<whatever>
/question/edit/<whatever>
/question/update/<whatever> (this is the post back url)
/question/list   (lists the questions)

Hmm. obrigado a qualquer um que esteja ajudando :)

rest 
— Pure.Krome
fonte

Respostas:

173

Use URLs para especificar seus objetos, não suas ações:

Observe que o que você mencionou primeiro não é RESTful:

/questions/show/<whatever>

Em vez disso, você deve usar seus URLs para especificar seus objetos:

/questions/<question>

Em seguida, você executa uma das operações a seguir nesse recurso.

PEGUE:

Usado para obter um recurso, consultar uma lista de recursos e também consultar informações somente leitura sobre um recurso.

Para obter um recurso de pergunta:

GET /questions/<question> HTTP/1.1
Host: whateverblahblah.com

Para listar todos os recursos de perguntas:

GET /questions HTTP/1.1
Host: whateverblahblah.com

POSTAR:

Usado para criar um recurso.

Observe que o seguinte é um erro:

POST /questions/<new_question> HTTP/1.1
Host: whateverblahblah.com

Se a URL ainda não foi criada, você não deve usar POST para criá-la ao especificar o nome. Isso deve resultar em um erro de recurso não encontrado porque ainda não existe. Você deve colocar o recurso no servidor primeiro. Você pode argumentar que, ao criar uma nova pergunta, você também está atualizando o recurso / questions, pois agora ele retornaria mais uma pergunta em sua lista de perguntas.

Você deve fazer algo assim para criar um recurso usando POST:

POST /questions HTTP/1.1
Host: whateverblahblah.com

Observe que, neste caso, o nome do recurso não é especificado, o novo caminho da URL do objeto será retornado para você.

EXCLUIR:

Usado para excluir o recurso.

DELETE /questions/<question> HTTP/1.1
Host: whateverblahblah.com

COLOCAR:

Usado para criar um recurso, ou sobrescrevê-lo, enquanto você especifica a URL dos recursos.

Para um novo recurso:

PUT /questions/<new_question> HTTP/1.1
Host: whateverblahblah.com

Para substituir um recurso existente:

PUT /questions/<existing_question> HTTP/1.1
Host: whateverblahblah.com

... Sim, eles são os mesmos. PUT é freqüentemente descrito como o método de 'edição', pois ao substituir o recurso inteiro por uma versão ligeiramente alterada, você editou o que os clientes OBTERÃO na próxima vez.

Usando REST em formulários HTML:

A especificação HTML5 define GET e POST para o elemento de formulário .

O atributo method content é um atributo enumerado com as seguintes palavras-chave e estados:

  • A palavra-chave GET, mapeando para o estado GET, indicando o método HTTP GET.
  • A palavra-chave POST, mapeando para o estado POST, indicando o método HTTP POST.

Tecnicamente, a especificação HTTP não o limita apenas a esses métodos. Você está tecnicamente livre para adicionar quaisquer métodos que desejar; na prática, porém, isso não é uma boa ideia. A ideia é que todos saibam que você usa GET para ler os dados, então isso vai confundir as coisas se você decidir usar READ. Dito isto...

FRAGMENTO:

Este é um método que foi definido em uma RFC formal. Ele foi projetado para ser usado quando você deseja enviar apenas uma modificação parcial de um recurso, ele seria usado de forma semelhante a PUT:

PATCH /questions/<new_question> HTTP/1.1
Host: whateverblahblah.com

A diferença é que PUT deve enviar todo o recurso, não importa quão grande seja comparado ao que foi realmente alterado, enquanto PATCH você pode enviar apenas as alterações.

— Brian R. Bondy
fonte
Oi Brian .. quanto mais eu leio isso, mais faz sentido. Estou assumindo que alguns navegadores (ou versões de navegadores) não suportam PUT ou DELETE? se for esse o caso, usamos POST em vez disso?
— Pure.Krome
1
Hi Pure.Knome; Os navegadores da Web oferecem suporte a todos eles, também qualquer biblioteca HTTP deve oferecer suporte a todos eles.
— Brian R. Bondy
4
Eu recomendaria comprar este livro se você quiser aprender tudo sobre REST oreilly.com/catalog/9780596529260
— Brian R. Bondy
1
@Brian: mais algumas perguntas sobre seus exemplos PUT. >> PUT / questions / <new_question> Por que você faria isso, em vez de >> PUT / questions / porque todos os dados no formulário serão usados ​​para criar o novo recurso? (continua no próximo comentário) ...
— Pure.Krome
1
@Brian R. Bondy, Obrigado pela ótima resposta. A solicitação POST para o recurso existente é descrita como "anexar" no livro repousante de oreilly (pág: 100,101), ao contrário do seu termo geral de "modificação". Afinal, acrescentar é mais específico do que modificar - o que pode transmitir "PUT para um recurso existente" - e semanticamente parece mais correto para POST - adicionar um novo recurso ao link especificado, seja acrescentando ou criando um recurso filho a esse .
— Özgür
11

Assumindo que /questions/10é uma questão válida, o método é usado para interagir com ela.

POST para adicionar a ele

PUT para criar ou substituir

GET para ver / consultar

e DELETE para bem .. delete.

O url não muda.

— Allain Lalonde
fonte
4
Errado. PUT deve ser idempotente. Você deve ser capaz de fazer a mesma solicitação PUT várias vezes, sem efeito após a primeira vez. Portanto, criar um recurso com cada solicitação PUT não é idempotente.
— aehlke de
3
"Os métodos PUT e DELETE são definidos para serem idempotentes, o que significa que várias solicitações idênticas devem ter o mesmo efeito que uma única solicitação.", Usar put em um URI que atualmente não disponibiliza um recurso pode criar um recurso. Colocar imediatamente de novo faria de novo, o que não teria efeito. Desta forma, você está criando um recurso, mas a consulta ainda é idempotente. Se você voltar mais tarde e desejar alterar o recurso, deverá usar PUT para o mesmo URI com dados diferentes (o que seria uma solicitação diferente e poderia ser repetido várias vezes com o mesmo resultado).
— Allain Lalonde
1
Na verdade, dê uma olhada na resposta que obteve 25 votos acima, afirma-se que PUT pode ser usado para criar ou substituir um recurso.
— Allain Lalonde
3
A criação só funciona enquanto a especificação do ID de um novo recurso for permitida. Embora seja possível, é mais frequentemente conveniente para o usuário fazer POST na / coleção e receber links que incluem o novo id:
— pgraham
2
@aehIke A criação de um novo recurso por PUT não o torna não idempotente, pois a ideia é que se eu 'PUT / items / 10' e o item 10 não existisse antes, então ele apenas seria criado. No entanto, se eu 'PUT / items / 10' novamente pela segunda vez, bem, agora ele já existe, então será apenas substituído, portanto, a idempotência é preservada, uma vez que as solicitações PUT subsequentes não têm nenhum novo efeito colateral. (É claro que isso pressupõe que eu continue colocando exatamente o mesmo item a cada vez)
— Alappin
3

Eu vou arriscar e supor que você quer dizer quais são os controladores padrão para MVC quando você diz urls "RESTful", já que seus exemplos podem ser considerados não "RESTful" (consulte este artigo).

Já que Rails realmente popularizou o estilo de URL que você parece estar interessado, eu ofereço abaixo as ações do controlador padrão produzidas pelo ScaffoldingGenerator em Ruby on Rails. Eles devem ser familiares a qualquer pessoa que use um aplicativo Rails.

As ações e visualizações do scaffold são: indexar, listar, mostrar, novo, criar, editar, atualizar, destruir

Normalmente, você construiria isso como:

http://application.com/controller/<action>/<id>
— Tvanfosson
fonte
5
As convenções de URI fora da banda NÃO são RESTful. Citando o próprio Fielding: "Uma API REST não deve definir nomes de recursos fixos ou hierarquias (um acoplamento óbvio de cliente e servidor). Os servidores devem ter a liberdade de controlar seu próprio namespace. Em vez disso, permita que os servidores instruam os clientes sobre como construir URIs apropriados , como é feito em formulários HTML e modelos de URI, definindo essas instruções dentro de tipos de mídia e relações de link .. "
— aehlke
1

Aqui está um mapeamento de seus URLs atuais usando o princípio REST:

/question/show/<whatever>

Se você identificar a pergunta como um recurso, ela deve ter um URL exclusivo. Usar GET para exibi-lo (recuperá-lo) é a prática comum. Se torna:

GET /question/<whatever>

/question/edit/<whatever>

Agora você deseja que seu usuário tenha outra visão do mesmo recurso que lhe permita editar o recurso (talvez com controles de formulário).

Duas opções aqui, seu aplicativo é um aplicativo (não um site), então você pode usar JavaScript para transformar o recurso em um recurso editável no lado do cliente.

Se este for um site, você pode usar o mesmo URL com informações adicionais para especificar outra visualização. A prática comum parece ser:

GET /question/<whatever>;edit

/question/update/<whatever> (this is the post back url)

Isso é para mudar a pergunta, então PUT é o método correto a ser usado:

PUT /question/<whatever>

/question/list   (lists the questions)

A lista de perguntas é, na verdade, o recurso pai de uma pergunta, então naturalmente é:

GET /question

Agora você pode precisar de mais alguns:

POST /question (create a new question and returns its URL)
DELETE /question/<whatever> (deletes a question if this is relevant)

Tada :)

— Vincent Robert
fonte
-1

Seus quatro exemplos podem ser:

GET /questions/123
POST (or PUT) /questions/123 q=What+is+the+meaning+of+life
POST (or PUT) /questions/123 q=What+is+the+meaning+of+life
GET /questions

Para adicionar uma pergunta:

POST /questions q=What+is+the+meaning+of+life

O servidor responderia:

200 OK (or 201 Created)
Location: /questions/456
— Pbreitenbach
fonte
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.