È ragionevole che le risorse REST siano singolari e plurali?

Question

È ragionevole che le risorse REST siano singolari e plurali?

#1 da (6 voti)
#2 da (1 voti)

9

Mi sono chiesto se, piuttosto che un layout più tradizionale come questo:

api/Products
GET // gets product(s) by id
PUT // updates product(s) by id
DELETE // deletes (product(s) by id
POST // creates product(s)

Sarebbe più utile avere un singolare e un plurale, ad esempio:

api/Product
GET // gets a product by id
PUT // updates a product by id
DELETE // deletes a product by id
POST // creates a product

api/Products
GET // gets a collection of products by id
PUT // updates a collection of products by id
DELETE // deletes a collection of products (not the products themselves)
POST // creates a collection of products based on filter parameters passed

Quindi, per creare una collezione di prodotti che potresti fare:

POST api/Products {data: filters} // returns api/Products/<id>

E poi, per fare riferimento, potresti fare:

GET api/Products/<id> // returns array of products

A mio parere, il vantaggio principale di fare le cose in questo modo è che consente una facile memorizzazione nella cache delle raccolte di prodotti. Si potrebbe, ad esempio, mettere una vita di un'ora su raccolte di prodotti, riducendo così drasticamente le chiamate su un server. Certo, al momento vedo solo il lato buono del fare le cose in questo modo, qual è il rovescio della medaglia?

rest

posta Eva 24.10.2012 - 16:48

fonte

2 risposte

1

Lo svantaggio è che anche il programma chiamante deve pluralizzare il nome della risorsa, il che può essere complicato per quei linguaggi client che non hanno meccanismi di pluralizzazione incorporati. Se lo lasci singolare, è più facile per il chiamante automatizzare la generazione del codice per la sua libreria client.

Se vuoi mitigare questo, puoi generare gli SDK per il tuo servizio REST tu stesso. Oppure, puoi solo essere supponente e affrontare la lamentela:)

risposta data 24.10.2012 - 16:57

fonte

Leggi altre domande sui tag rest

Flowcharting e Method Calls Chi ha creato o reso popolare l'XMLHTTPRequest / MSXML originale?

score 6 · Accepted Answer

Spesso quando una raccolta diventa il modo più utile di interagire con la tua API, può essere più semplice pensare a una singola come una raccolta con un solo membro. Quindi se successivamente vuoi esporre un'API per interagire con i singoli, è sufficiente che sotto le copertine converti il singolo passato in una raccolta con quel membro e poi utilizzi l'implementazione identica dell'altra API.

Credo che quello che sto dicendo sia che, se vuoi che le collezioni siano un meccanismo di interazione, inizia con la raccolta solo API e dopo che il sistema è completo, l'altra API è una semplice connessione ausiliaria a livello di interfaccia che puoi aggiungi poi se lo trovi particolarmente utile. Puoi comunque scoprire che l'utilità è minima sufficiente per applicare YAGNI e utilizzare l'interfaccia delle raccolte solo per le poche istanze di singoli che desideri.