REST kaynaklarının tekil ve çoğul olması makul müdür?

Bunun gibi daha geleneksel bir düzen yerine, merak ediyorum:

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

Tekil ve çoğul olmak daha yararlı olur mu, örneğin:

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

Yani, yapabileceğiniz bir ürün koleksiyonu oluşturmak için:

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

Ve sonra, referans vermek için şunları yapabilirsiniz:

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

Kanımca, işleri bu şekilde yapmanın ana avantajı, ürün koleksiyonlarının kolayca önbelleğe alınmasına izin vermesidir. Örneğin, ürün koleksiyonlarına bir saatlik bir ömür verilebilir, böylece bir sunucudaki çağrılar büyük ölçüde azalır. Tabii ki, şu anda işleri bu şekilde yapmanın sadece iyi tarafını görüyorum, olumsuz tarafı nedir?

rest

— Eva
kaynak

Yanıtlar:

Genellikle bir koleksiyon, API'nizle etkileşim kurmanın en yararlı yolu olacağı zaman, tek bir parçayı yalnızca bir üyeli bir koleksiyon olarak düşünmek daha kolay olabilir. Daha sonra, bekarlarla etkileşime girmek için bir API'yi ortaya çıkarmak istiyorsanız, yalnızca kapakların altında geçirilen tek bir üyeyi bu üyeyle birlikte bir koleksiyona dönüştürmesi gerekir ve daha sonra diğer API'nin aynı uygulamasını kullanır.

Sanırım burada söylediğim şey, eğer koleksiyonların bir etkileşim mekanizması olmasını istiyorsanız, sadece koleksiyon API'sı ile başlayın ve sistem tamamlandıktan sonra, diğer API arayüz katmanında basit bir yardımcı ektir. özellikle yararlı buluyorsunuz. Bununla birlikte, YAGNI'yi uygulayacak kadar kullanışlı olduğunu ve koleksiyon arayüzünü istediğiniz tekli birkaç örnek için kullanacağınızı görebilirsiniz.

— Jimmy Hoffa
kaynak

Yeni örneğin oluşturulması için veri değil, toplama filtresi parametrelerini iletmek için POST api / Products kullanılacağı göz önüne alındığında, yukarıdaki örneği kullandığımızı varsayarsak, sizin görüşünüze katılırken, yeni bir ürün oluşturmak için makul bir yol ne olacaktır? api olmadan / Ürün?

— Eva

@Evan Neden api / Products'a birden fazla (veya bir ürün koleksiyonunu) Ürün ekleyemiyorum? Bu benim için en mantıklı görünüyor. Belki de filtreler oluşturmak için Ürünler / Filtre yayınlayın veya yaratıcı bir görev değil, bir geri alma işlevi olup olmadığını öğrenin.

— Jimmy Hoffa

Ayrıntı için teşekkürler Jimmy. Bunu bu şekilde görmememin sebebi, yukarıdaki örnekte, koleksiyonu kendi içinde tanımlanmış bir kaynak olarak görmemdi. Bir arka uçta, api / Ürün "Ürün" ve api / Ürünler dolayısıyla "ProductCollection" olabilir. Ancak, bazı değerlendirmelerden sonra, önerinizde olduğu gibi API'dan tamamen uzaklaşmanın ... şimdi asıl soruya göre, Tayland'a giderken o kamyon tepesinden uzaklaştınız mı, yoksa ayrıldınız mı? bir arabanın bagajında?

— Eva

@Evan Sana iki ipucu vereceğim: Martılar.

— Jimmy Hoffa

Dezavantajı, çağıran programın, dahili çoğullaştırma mekanizmalarına sahip olmayan istemci dilleri için zor olabilen kaynak adını çoğaltması gerektiğidir. Tekil olarak bırakırsanız, arayan kişinin istemci kitaplığı için kod oluşturmayı otomatikleştirmesi daha kolaydır.

Bunu azaltmak isterseniz, REST hizmetiniz için SDK'ları kendiniz oluşturabilirsiniz. Ya da sadece görüşülüp şikayette bulunabilirsiniz :)

— Chris McCall
kaynak