Quali sono i verbi e le azioni dell'URL RESTful migliori / comuni?

86

Sto cercando di trovare alcune informazioni sulle azioni URL RESTful migliori e più comuni.

ad esempio, quale URL usi per visualizzare i dettagli di un elemento, per modificare l'elemento, aggiornare, ecc.

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

hmm. grazie a chiunque dia una mano :)

rest 
— Pure.Krome
fonte

Risposte:

174

Usa gli URL per specificare i tuoi oggetti, non le tue azioni:

Nota ciò che hai menzionato per la prima volta non è RESTful:

/questions/show/<whatever>

Invece, dovresti usare i tuoi URL per specificare i tuoi oggetti:

/questions/<question>

Quindi esegui una delle operazioni seguenti su quella risorsa.

OTTENERE:

Utilizzato per ottenere una risorsa, interrogare un elenco di risorse e anche per richiedere informazioni di sola lettura su una risorsa.

Per ottenere una risorsa per le domande:

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

Per elencare tutte le risorse per le domande:

GET /questions HTTP/1.1
Host: whateverblahblah.com

INVIARE:

Utilizzato per creare una risorsa.

Tieni presente che il seguente è un errore:

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

Se l'URL non è ancora stato creato, non dovresti usare POST per crearlo mentre specifichi il nome. Ciò dovrebbe causare un errore di risorsa non trovata perché non esiste ancora. Dovresti prima METTERE la risorsa sul server. Potresti sostenere che creando una nuova domanda, stai anche aggiornando la risorsa / questions poiché ora restituirebbe un'altra domanda nel suo elenco di domande.

Dovresti fare qualcosa di simile per creare una risorsa usando POST:

POST /questions HTTP/1.1
Host: whateverblahblah.com

Notare che in questo caso il nome della risorsa non è specificato, verrà restituito il percorso dell'URL del nuovo oggetto.

ELIMINA:

Utilizzato per eliminare la risorsa.

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

METTERE:

Utilizzato per creare una risorsa o sovrascriverla mentre si specifica l'URL delle risorse.

Per una nuova risorsa:

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

Per sovrascrivere una risorsa esistente:

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

... Sì, sono la stessa cosa. PUT è spesso descritto come il metodo di "modifica", poiché sostituendo l'intera risorsa con una versione leggermente modificata, hai modificato ciò che i client OTTERRANNO quando lo faranno.

Utilizzo di REST nei moduli HTML:

La specifica HTML5 definisce GET e POST per l'elemento del modulo .

L'attributo del contenuto del metodo è un attributo enumerato con le seguenti parole chiave e stati:

  • La parola chiave GET, mappata allo stato GET, che indica il metodo HTTP GET.
  • La parola chiave POST, mappata allo stato POST, che indica il metodo HTTP POST.

Tecnicamente, la specifica HTTP non ti limita solo a questi metodi. Sei tecnicamente libero di aggiungere tutti i metodi che desideri, ma in pratica non è una buona idea. L'idea è che tutti sappiano che usi GET per leggere i dati, quindi confonderebbe le cose se decidi di usare invece READ. Detto ciò...

PATCH:

Questo è un metodo definito in un RFC formale. È progettato per essere utilizzato quando si desidera inviare solo una modifica parziale a una risorsa, sarebbe usato in modo molto simile a PUT:

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

La differenza è che PUT deve inviare l'intera risorsa, non importa quanto sia grande rispetto a ciò che è effettivamente cambiato, mentre PATCH puoi inviare solo le modifiche.

— Brian R. Bondy
fonte
Ciao Brian .. più leggo questo, più ha senso. Presumo che alcuni browser (o versioni di browser) non supportino PUT o DELETE? se è così, usiamo invece POST?
— Pure.Krome
1
Ciao Pure.Knome; I browser Web li supportano tutti, anche qualsiasi libreria HTTP dovrebbe supportarli tutti.
— Brian R. Bondy
4
A proposito, consiglierei di acquistare questo libro se vuoi imparare tutto su REST oreilly.com/catalog/9780596529260
— Brian R. Bondy
1
@ Brian: qualche altra domanda sui tuoi esempi PUT. >> PUT / questions / <new_question> Perché dovresti farlo invece di >> PUT / questions / perché tutti i dati nel modulo verranno usati per creare la nuova risorsa? (continua commento successivo) ...
— Pure.Krome
1
@Brian R. Bondy, grazie per la tua ottima risposta. La richiesta POST alla risorsa esistente è descritta come "aggiunta" nel libro riposante di oreilly (pag: 100,101), contrariamente al termine generale di "modifica". Dopotutto, aggiungere è più specifico che modificare - che può trasmettere "PUT a una risorsa esistente" - e semanticamente suona più corretto per POST - aggiungendo una nuova risorsa al collegamento specificato, aggiungendo o creando una risorsa figlia a quello .
— Özgür
11

Supponendo che /questions/10sia una domanda valida, il metodo viene utilizzato per interagire con essa.

POST da aggiungere ad esso

Metti per crearlo o sostituirlo

OTTIENI per visualizzarlo / interrogarlo

e CANCELLA per bene .. cancellalo.

L'URL non cambia.

— Allain Lalonde
fonte
4
Sbagliato. PUT deve essere idempotente. Devi essere in grado di effettuare la stessa richiesta PUT molte volte, senza alcun effetto dopo la prima volta. Quindi, creare una risorsa con ogni richiesta PUT non è idempotente.
— aehlke
3
"I metodi PUT e DELETE sono definiti idempotenti, il che significa che più richieste identiche dovrebbero avere lo stesso effetto di una singola richiesta.", Utilizzando put in un URI che attualmente non rende disponibile una risorsa può creare una risorsa. Mettere immediatamente di nuovo lo farebbe di nuovo, il che non avrebbe alcun effetto. In questo modo stai creando una risorsa, ma la query è ancora idempotente. Se in seguito torni e desideri modificare la risorsa, man PUT sullo stesso URI con dati diversi (che sarebbe una richiesta diversa e potrebbe essere ripetuta un numero qualsiasi di volte con lo stesso risultato).
— Allain Lalonde
1
In realtà, dai un'occhiata alla risposta che ha ricevuto 25 voti sopra, si afferma che PUT può essere utilizzato per creare o sostituire una risorsa.
— Allain Lalonde
3
La creazione funziona solo fintanto che è consentito specificare l'ID di una nuova risorsa. Sebbene sia possibile, è più spesso più conveniente per l'utente inviare a / collection e restituire link che includono il nuovo id:
— pgraham
2
@aehIke La creazione di una nuova risorsa da parte di PUT non la rende non idempotente poiché l'idea è che se "PUT / items / 10" e l'elemento 10 non esistessero prima, verrà semplicemente creato. Tuttavia, se "PUT / items / 10" di nuovo per la seconda volta, beh, ora esiste già, quindi verrà semplicemente sostituito, quindi l'idempotenza viene preservata poiché le successive richieste PUT non hanno nuovi effetti collaterali. (Ovviamente si presume che continui a mettere lo stesso identico articolo ogni volta)
— Alappin
3

Vado fuori di testa e immagino che ciò che intendi sia ciò che sono controller standard per MVC quando dici URL "RESTful", poiché i tuoi esempi potrebbero essere considerati non- "RESTful" (vedi questo articolo).

Dato che Rails ha davvero reso popolare lo stile dell'URL a cui sembri essere interessato, offro di seguito le azioni predefinite del controller prodotte da ScaffoldingGenerator in Ruby on Rails. Dovrebbero essere familiari a chiunque utilizzi un'applicazione Rails.

Le azioni e le viste di scaffolding sono: index, list, show, new, create, edit, update, eliminate

In genere lo costruiresti come:

http://application.com/controller/<action>/<id>
— tvanfosson
fonte
5
Le convenzioni URI fuori banda NON sono RESTful. Citando lo stesso Fielding: "Un'API REST non deve definire gerarchie o nomi di risorse fisse (un ovvio accoppiamento di client e server). I server devono avere la libertà di controllare il proprio spazio dei nomi. Invece, consentire ai server di istruire i client su come costruire URI appropriati , come avviene nei moduli HTML e nei modelli URI, definendo tali istruzioni all'interno dei tipi di media e delle relazioni di collegamento .. "
— aehlke
1

Ecco una mappatura dei tuoi URL correnti utilizzando il principio REST:

/question/show/<whatever>

Se identifichi la domanda come una risorsa, dovrebbe avere un URL univoco. Usare GET per visualizzarlo (recuperarlo) è una pratica comune. Diventa:

GET /question/<whatever>

/question/edit/<whatever>

Ora vuoi che il tuo utente abbia un'altra vista della stessa risorsa che gli consenta di modificare la risorsa (magari con i controlli del modulo).

Due opzioni qui, la tua applicazione è un'applicazione (non un sito web), quindi potresti usare meglio JavaScript per trasformare la risorsa in una risorsa modificabile sul lato client.

Se si tratta di un sito Web, è possibile utilizzare lo stesso URL con informazioni aggiuntive per specificare un'altra vista, la pratica comune sembra essere:

GET /question/<whatever>;edit

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

Questo per cambiare la domanda, quindi PUT è il metodo corretto da usare:

PUT /question/<whatever>

/question/list   (lists the questions)

L'elenco delle domande è in realtà la risorsa principale di una domanda, quindi è naturalmente:

GET /question

Ora potresti aver bisogno di altro:

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

I tuoi quattro esempi potrebbero essere:

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

Per aggiungere una domanda:

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

Il server risponderebbe:

200 OK (or 201 Created)
Location: /questions/456
— pbreitenbach
fonte
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.