È ragionevole che le risorse REST siano singolari e plurali?

Mi chiedevo 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 raccolta di prodotti 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 avviso, il vantaggio principale di fare le cose in questo modo è che consente una facile memorizzazione nella cache delle raccolte di prodotti. Ad esempio, si potrebbe dedicare un'ora di vita a raccolte di prodotti, riducendo drasticamente le chiamate su un server. Naturalmente, attualmente vedo solo il lato positivo di fare le cose in questo modo, qual è il rovescio della medaglia?

rest

— Eva
fonte

Risposte:

Spesso quando una raccolta sarà il modo più utile di interagire con l'API, può essere più semplice pensare a un singolo come a una raccolta con un solo membro. Quindi, se in seguito desideri esporre un'API per l'interazione con singoli, deve semplicemente convertire sotto le copertine il singolo passato in una raccolta con quel membro e quindi utilizza l'implementazione identica dell'altra API.

Immagino che ciò che sto dicendo qui sia, se vuoi che le raccolte siano un meccanismo di interazione, inizia con l'API solo raccolta e dopo che il sistema è completo, l'altra API è un semplice attacco accessorio a livello di interfaccia che puoi aggiungere se lo trovi particolarmente utile. Tuttavia, potresti scoprire che l'utilità è abbastanza minima per applicare YAGNI e utilizzare semplicemente l'interfaccia delle raccolte per le poche istanze di singoli che desideri.

— Jimmy Hoffa
fonte

Mentre sono d'accordo con il tuo sentimento, supponendo che usiamo l'esempio sopra, dato che api / prodotti POST verrebbero utilizzati per passare i parametri del filtro di raccolta e non i dati per la creazione di nuovi prodotti, quale sarebbe un modo ragionevole per creare un nuovo prodotto senza api / prodotto?

— Eva,

@Evan Perché non è possibile pubblicare su api / prodotti inserire più (o una raccolta di uno) prodotti? Questo mi sembra il più logico. Forse pubblica prodotti / filtri per la creazione di filtri o ottieni se sono un'attività di recupero e non di creazione.

— Jimmy Hoffa,

Grazie per l'elaborazione, Jimmy. La ragione per cui non la vedevo in questo modo era che stavo considerando, nell'esempio sopra, la raccolta come una risorsa identificata in sé e per sé. Su un backend, api / Product potrebbe essere "Product" e api / Products quindi "ProductCollection". Tuttavia, dopo un po 'di considerazione, penso che potrebbe essere meglio sottrarre tutto ciò dall'API, come nel tuo suggerimento ... ora alla vera domanda, ti sei allontanato da quel camion sulla strada per la Thailandia o sei partito nel bagagliaio di un'auto?

— Eva,

@Evan Ti darò due suggerimenti: Gabbiani.

— Jimmy Hoffa,

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

Se si desidera mitigarlo, è possibile generare autonomamente gli SDK per il servizio REST. Oppure, puoi solo essere supponente e gestire i lamenti :)

— Chris McCall
fonte