2013-08-18 10 views
6

Recentemente ho iniziato a provare a pensare come RESTfully possibile, e mi trovo ostacolato dalle rotte non ovvie.RESTful modo per verificare la disponibilità di nomi utente, e-mail, ecc.

In questo caso particolare, sono curioso del modo RESTful di verificare la disponibilità del nome utente e della posta elettronica per un utente o qualsiasi altra cosa che abbia univocità.

Il mio istinto mi dice che vorrei effettuare una GET su /users/email o /users/username/ ciascuno con un param necessaria, o qualcosa sulla falsariga di GET /users/search/ con params opzionali di email e username. Se ottieni 200, lo username o email non è disponibile; se ottieni un 404, allora è disponibile.

Preferisco la prima opzione dal momento che è più esplicita, ma non è che abbia riflettuto sulla tesi di Roy Fielding per sapere abbastanza bene cosa fare.

Qual è l'approccio più corretto qui?

risposta

4

Il primo approccio sembra essere più "RESTful". Si tenta di ottenere una risorsa specifica (tramite nome utente o e-mail) e ottenerla se esiste o ottenere un messaggio di stato "risorsa non disponibile". Questo sarebbe:

  • GET/Users/nomeutente/John Wayne (per "ottenere" John Wayne la disponibilità delle risorse/nomeutente ...)

Questo dovrebbe generare:

  • 200: se risorsa esiste
  • 404: se la risorsa non esiste

la seconda o sembra più simile al servizio web "SOAP", dove si definisce una "funzione" (/ users/search /) con alcuni "parametri" (username, email) ...

+0

Li ho modificati perché se la risorsa esiste, non è disponibile. Se non esiste, è disponibile. –

+1

scusa (modificherò la mia risposta) ... Non ho "letto" in questo modo, vuoi dire che restituisce "200" se il nome utente è disponibile ... Capisco, ma è un po 'confuso secondo la semantica di la risorsa GET. Forse dovresti considerare di gestirlo nel client, cioè, nel client tu controlli se la risorsa non è disponibile puoi crearla (il nome utente è disponibile) ... Ma questa è la mia interpretazione, penso che ci sia un bel po 'di spazio per l'interpretazione :) – emgsilva

1

Per i campi univoci, la prima opzione è un buon adattamento (/ utenti/email o/utenti/nome utente /), per la ricerca di campi non univoci sarebbe più appropriato.

0

Si consiglia di utilizzare la richiesta HEAD anziché GET.

L'utilizzo di un GET può rappresentare un problema di sicurezza. Un hacker può utilizzare una combinazione di individuare nome utente corretto come GET sarebbe o la combinazione 200 o 404.

0

Si dovrebbe cercare di ottenere una lista di utenti con la posta da

GET /[email protected] 

E qui si possono trovare 1 articolo o 0 articoli. Nel primo caso l'indirizzo non è univoco. In un altro - è univoco

Problemi correlati