REST - supporto di più identificatori possibili

Question

Per il sito su cui sto lavorando, stiamo migliorando i nostri URL per un tipo di risorsa, in particolare spostando gli ID numerici verso stringhe univoche e descrittive. Un esempio simile potrebbe essere il passaggio dall'identificazione degli utenti tramite l'ID numerico del database all'identificazione per nome utente (non il caso specifico, ma analogo). Quindi un URL per accedere alle informazioni di un utente utilizzato per assomigliare:

/users/48573 

Ed ora sembra che

/users/thisisausername. 

L'unico problema è che abbiamo ancora bisogno di essere in grado di prendere loro attraverso gli ID numerici in qualche modo , per i clienti legacy dell'API. Non abbiamo bisogno gli URL riposarsi per reindirizzare (ad esempio /users/48573 non dovrebbe reindirizzare a /users/thisisausername), abbiamo solo bisogno di un metodo per ottenere i dati corretti utilizzando il vecchio identificativo. La soluzione dovrebbe fornire un modo alternativo di accedere alle informazioni dell'utente (che include comodamente il nuovo identificativo, nome utente) per ID o di accedere solo al nome utente per ID. Alcune possibili soluzioni potrebbero essere:

• Utilizzare un nodo per specificare un metodo alternativo di identificazione, ad es. /users/byid/48573
• Utilizzando un parametro di query per specificare un metodo alternativo di identificazione, ad esempio /users/48573?fetchby=id o /users/48573?byid=true
• Trattamento nome utente-by-id come un'altra risorsa, ad esempio /identifiers/username/48573

Quale di questi (se presente) è più vicino al REST corretto? Come affronteresti il ​​problema?

Answer 1

La prima opzione è probabilmente il migliore.

Ricerca di utenti da ID:

/users/id/48573 

Ricerca per gli utenti per nome breve:

/users/name/thisisausername 

Se lasciano che il parametro percorso, si può sempre di default per il vostro nuovo formato nome utente breve.

Un'altra opzione che ho visto un bel po 'è quello di utilizzare parametri di query come la seguente:

/users?id=48573 
/users?name=thisisausername 

Credo che il primo sembra un po' più pulito e più leggibile.

Answer 2

mi piacerebbe prendere in considerazione le qualifiche la stringa con un suffisso opzionale:

/users/48573/id 

/users/48573/name 

Se si riceve una stringa senza il suffisso:

/users/48573 

quindi di controllare la stringa e vedere se si tratta di un ID o nome.

Se si ottiene solo un documento d'identità valido, ma non un nome, allora si tratta di un recupero per ID equivalente a:

/users/48573/id 

Se si ottiene solo un nome allora si tratta di un recupero per nome equivalente a:

/users/48573/name 

Se è possibile recuperare il valore per ID o il nome, allora si restituisce un errore 300 di risposta e ritorni collegamenti per entrambi possiblities al client:

/users/48573/id 

/users/48573/name 

I clienti legacy continuano a funzionare "così come sono" tranne che per il verificarsi occasionale di coppie ID/nome duplicate in cui ricevono il nuovo 300 errore di risposta.

Answer 3

L'API non è RESTful se questo è un problema. A quote Roy Fielding:

Un'API REST non deve definire nomi di risorse fisse o gerarchie (un accoppiamento ovvio di client e server). I server devono avere la libertà di controllare il proprio spazio dei nomi. Invece, consentire ai server di istruire i clienti 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. [L'insuccesso qui implica che i clienti stiano assumendo una struttura di risorse a causa di informazioni fuori banda, come uno standard specifico del dominio, che è l'equivalente orientato ai dati dell'accoppiamento funzionale di RPC].

Un'API REST deve essere immessa senza alcuna conoscenza preliminare oltre l'URI iniziale (segnalibro) e un insieme di tipi di supporti standardizzati appropriati per il pubblico previsto (vale a dire, è previsto che vengano compresi da qualsiasi client che potrebbe utilizzare l'API) . Da quel momento in poi, tutte le transizioni dello stato dell'applicazione devono essere guidate dalla selezione dei client delle scelte fornite dal server presenti nelle rappresentazioni ricevute o implicite dalla manipolazione dell'utente di tali rappresentazioni. Le transizioni possono essere determinate (o limitate dalla) conoscenza da parte del cliente dei tipi di media e dei meccanismi di comunicazione delle risorse, entrambi possono essere migliorati al volo (ad esempio, code-on-demand). [Il fallimento qui implica che le informazioni fuori banda stanno guidando l'interazione invece dell'ipertesto.]

Answer 4

Penso che aggiungere un segmento segmento/prefisso sia la risposta migliore. Poiché si tratta di chiavi secondarie univoche, non è la stessa cosa della ricerca (che restituisce un insieme di elementi), quindi l'utilizzo dei parametri di query (che non sono memorizzati nella cache) non sembra la scelta migliore.

Personalmente, ho intenzione di utilizzare un prefisso segmento di percorso delimitato da "=", come "name =" o "email =":

user/123456 
user/name=john.doe 
user/email=john.doe@john.doe 

Questo è funzionalmente equivalente ad aggiungere un segmento di percorso (ad esempio " user/name/john.doe "), ma mi sembra come se fosse più vicino al modello concettuale. Ovviamente, questo è un dettaglio insignificante, poiché le API RESTful non dovrebbero comunque specificare una struttura URI fissa.

Non utilizzando parametri di query consente anche sotto-risorse a cui accedere, naturalmente:

user/name=john.doe/inbox/df87bhJXrg63 

Framework come di Java JAX-RS supportano utilizzando qualsiasi delimitatore che vuoi:

@GET 
@Path("user/{id}") 
User getUser(@PathParam("id") UUID id); 

@GET 
@Path("user/name={name}") 
User getUserByName(@PathParam("name") String name); 

@GET 
@Path("user/email={email}") 
User getUserByEmail(@PathParam("email") String email); 

Answer 5

Piuttosto una vecchia questione, ma Ho avuto lo stesso e finnaly trovato la soluzione: usa regex nel tuo percorso param.

Ecco come ho codificato questo caso l'uso

@GET 
@Path("/{id : \\d+}") 
@Produces(APPLICATION_JSON) 
public Response getById(@PathParam("id") long id) { 
<<your code>> 
} 

@GET 
@Path("/{name}") 
@Produces(APPLICATION_JSON) 
public Response getByName(@PathParam("name") String name) { 
<<your code>> 
}