L'URL 'utenti / nuovi' RESTful?

Question

L'URL 'utenti / nuovi' RESTful?

#1 da (3 voti)

2

Ero in un colloquio di lavoro che dimostrava un'API RESTful in Flask quando un argomento si rompeva sull'API. L'intervistatore ha affermato che l'URL per l'aggiunta di un nuovo utente ( /users/new ) non è corretto REST.

Il mio endpoint dell'API era simile a quello riportato di seguito:

GET /users       # get all users
GET /users/1     # get user 1
DELETE /users/1  # delete user 1
POST /users/new  # add new user

La sua tesi

Dovrebbe essere /users per coerenza con il resto dell'API.
Dovrebbe essere /users perché l'operazione è nel metodo HTTP stesso ( POST ) quindi new non è coerente.

La mia tesi

L'URL può essere qualsiasi cosa purché punti a una risorsa e che sia più una cosa stilistica.
RubyOnRais utilizza questa convenzione in modo che non possa essere completamente sbagliata.

In retrospezione ottengo la validità della sua argomentazione. Tuttavia, contraddice ciò che sta facendo uno dei framework web più popolari. Esiste un consenso su come può essere un URL e cosa no in una API RESTful? In questo caso è sbagliato un intero framework web?

Un altro modo di vedere questo è che /users è un "multiplo di utenti" mentre /users/x corrisponde a "singolo utente", nel qual caso la convenzione che ho usato ha senso.

rest conventions standards ruby-on-rails url

posta Pithikos 08.03.2018 - 13:39

fonte

1 risposta

Leggi altre domande sui tag rest conventions standards ruby-on-rails url

Sta sostituendo la chiamata a metodi di mutuo esclusivismo con una strategia di iniezione forzata? Il modello publish-subscribe è adatto al mio caso?

score 3 · Accepted Answer

REST non si cura di quale ortografia si usa per l'URI

Stefan Tilkov REST: non penso significhi cosa pensi che sia

Esempio: quando hai inviato questa domanda allo stack exchange, aggiungendo una "nuova" domanda alla raccolta /questions , hai dovuto esaminare l'URI per farlo? No certo che no. Tutto quello che dovevi fare era inviare il modulo.

REST si preoccupa quando viene utilizzato lo spelling same . Ad esempio, RFC 7234 descrive invalidazione della cache

A cache MUST invalidate the effective Request URI (Section 5.5 of [RFC7230]) as well as the URI(s) in the Location and Content-Location response header fields (if present) when a non-error status code is received in response to an unsafe request method.

Quindi potresti voler dare alla collezione un identificatore (es: /users ) e poi usare lo stesso identificatore sia per leggere la raccolta che per modificarla, fornendo ai componenti intermedi le informazioni di cui hanno bisogno in modo che non rispondano alle richieste con copie di rappresentazioni stantie.

(Nota: non c'è magia - il tuo POST sta per invalidare la rappresentazione nella tua cache locale, ma la mia cache locale rimarrà invariata; lavorare su dati obsoleti fino a quando la mia cache non viene invalidata).

In altre parole, si invia il "creare un messaggio utente" alla stessa risorsa del messaggio "ottieni tutti gli utenti" per lo stesso motivo per cui si invia il messaggio "elimina un utente specifico" allo stesso URI di " ottenere un "utente specifico": in modo che i componenti dell'intermediario possano contribuire utilmente.

Quindi

GET  /49647c1e-1441-46ea-80a3-676d3c02884b   # get all users
POST /49647c1e-1441-46ea-80a3-676d3c02884b   # add a new user

GET    /2a834d1a-a8d3-4dac-86e7-ca29d15a1eb2   # get user 1
DELETE /2a834d1a-a8d3-4dac-86e7-ca29d15a1eb2   # delete user 1

e puoi utilizzare qualsiasi ortografia che ti piace per quegli URI.