Identifica l'elemento con un ID o uno slug in un'API RESTful

Question

Attualmente sto progettando un'API e ho riscontrato un piccolo problema: Come dovrebbe apparire un URL di un'API RESTful quando dovresti essere in grado di identificare un oggetto con un ID o una lumaca?

riuscivo a pensare a tre opzioni:

GET /items/<id> 
GET /items/<slug> 

Ciò richiede che la lumaca e l'ID sono distinguibili, che non è necessariamente dato in questo caso. Non riesco a pensare a una soluzione pulita per questo problema, tranne che si fa qualcosa di simile:

GET /items/id/<id> 
GET /items/slug/<slug> 

Questo avrebbe funzionato bene, ma questo non è l'unico posto dove voglio identificare gli elementi da una una lumaca o un ID e sarebbe presto diventato molto brutto quando si vuole implementare lo stesso approccio per le altre azioni. E 'solo che non molto estensibile, che ci porta a questo approccio:

GET /items?id=<id> 
GET /items?slug=<slug> 

Questa sembra essere una buona soluzione, ma non so se è quello che ci si aspetterebbe, e quindi potrebbe portare a errori frustrante dovuti a un uso non corretto. Inoltre, non è così semplice - o diciamo pulito - implementare il routing per questo. Tuttavia, sarebbe facilmente estensibile e sarebbe molto simile al metodo per ottenere gli oggetti multipli:

GET /items?ids=<id:1>,<id:2>,<id:3> 
GET /items?slugs=<slug:1>,<slug:2>,<slug:3> 

Ma questo ha anche un rovescio della medaglia: cosa succede se qualcuno vuole identificare alcune delle voci che vogliono andare a prendere con ID, ma gli altri con una lumaca? Mischiare questi identificatori non sarebbe facile da ottenere con questo.

Qual è la soluzione migliore e più ampiamente accettata per questi problemi ? In generale, cosa conta durante la progettazione di tale API?

Answer 1

Dei tre preferisco la terza opzione, non è raro vedere questa sintassi; per esempio. parti di API di Twitter permettono che la sintassi: https://dev.twitter.com/rest/reference/get/statuses/show/id

Una quarta opzione è un approccio ibrido, in cui si sceglie uno (ad esempio, ID) come il metodo di accesso tipico per singole voci, ma consentono anche di query basate sulla lumaca. Es .:

GET /items/<id> 
GET /items?slug=<slug> 
GET /items?id=<id> 

tuo percorso sarà evidente mappa/oggetti/id/macchine? Id =

estensibile a più ID/lumache, ma ancora incontra il paradigma REST di corrispondenza URI al modello di dati sottostante.