RESTful API'de eğik çizgi

Bir RESTful API’da sondaki eğik çizgiyle ne yapılacağı hakkında tartışıyorum.

Diyelim ki, köpekler adı verilen bir kaynağım var ve bireysel köpekler için alt kaynaklar var. Bu nedenle aşağıdakileri yapabiliriz:

GET/PUT/POST/DELETE http://example.com/dogs
GET/PUT/POST/DELETE http://example.com/dogs/{id}

Fakat aşağıdaki özel durumla ne yapacağız:

GET/PUT/POST/DELETE http://example.com/dogs/

Benim kişisel görüşüm, bunun id = tek tek bir köpek kaynağına istek gönderdiğini söylüyor null. API'nin bu durumda 404 döndürmesi gerektiğini düşünüyorum.

Diğerleri, isteğin köpeklerin kaynağına ulaşmakta olduğunu, yani sondaki bağlantının göz ardı edildiğini söylüyor.

Kesin cevabı bilen var mı?

api rest http

— Gaz_Edge
kaynak

RESTful yolunun, köpek / kimliği ve köpekleri birbirinden ayırmak olduğunu düşündüm (tüm köpekleri ifade eder).

— pdr

RESTful Web Services adlı kitaptan - alt kaynaklar: başka bir “üst” kaynakla ilişkili olan kaynaklar yani dogs / {id} Web etkin bir veritabanı, bir tabloyu kaynak olarak gösterebilir ve ayrı veritabanı, alt kaynaklar olarak sıralanır .

— Gaz_Edge,

Köpek kaynağına erişiyor, sondaki boşluk göz ardı edilmeli, bu da silme uygulanmaması gereken bir şeyi silmeye çalışırken yasak bir yanıt alması gerektiği anlamına geliyor. Sanırım 404 de kabul edilebilir. Yine de önemli mi?

— Benjamin Gruenbaum

Takip etmiyorum - köpekleri silemeyeceğini kim söyledi? Köpekleri silerseniz, kendini ve bütün köpekleri siler. Bu yüzden köpeklere çağrı yapılmasına izin vermenin riskli olduğunu düşünüyorum. Müşteri bireysel bir köpeği silmek istese de, yanlışlıkla {id} 'yi bıraktıysa. Sonuç, tüm köpeklerin silinmesi olur. Çok daha güvenli takdirde boş {id} istiyor varsayalım ve 404 dönmek

— Gaz_Edge

Ben dogsve dogs/eşdeğer olarak tedavi ediyorum . Benim dogs/için bireysel köpekleri içeren bir dizin olduğu açıktır . Ne dogsolduğu daha az net değil , ama ben de eşit olarak kabul ediyorum, tıpkı çoğu web sunucusu izlemeden dizine erişimi kabul ediyor /.

— CodesInChaos

Yanıtlar:

Bunların hiçbiri yetkili değil (REST'in kesin bir anlamı olmadığı için). Ancak, REST'teki orijinal belgede tam (/ ile bitmeyen) URL kaynak olarak adlandırılırken, '/' eğik çizgi ile biten bir kaynak grubudur (muhtemelen böyle bir ifade verilmez).

Sonunda eğik çizgiye sahip bir URL’nin bir GET’inin kullanılabilir kaynakları listelemesi beklenir.

GET http://example.com/dogs/          /* List all the dogs resources */

Bütün kaynakları değiştirmek için eğik çizgiye sahip bir URL’de bir PUT olması gerekiyor.

PUT http://example.com/dogs/          /* Replace all the dogs resources */

Tüm kaynakları silmek için eğik çizgiye sahip bir URL’deki bir SİLME

DELETE http://example.com/dogs/       /* Deletes all the dogs resources */

Yeni bir kaynak oluşturmak için eğik çizgiye sahip bir URL'deki bir POST'a daha sonra erişilebilir. Uygun olması için yeni kaynak bu dizinde bulunmalıdır (yine de birçok RESTful mimarisi burada hile yapıyor).

POST http://example.com/dogs/        /* Creates a new dogs resource (notice singular) */

vb.

Konuyla ilgili wiki sayfası bunu iyi açıklıyor gibi görünüyor:

Bkz. Örneğin https://en.wikipedia.org/wiki/Representational_state_transfer#Applied_to_Web_services .

— Martin York
kaynak

Ayrıca, dizinlerin genellikle bir /

— izlemeyle

Öyleyse iz bırakmadan bir kaynak grubuna erişirseniz ne olmalı /?

— oberlies

@oberlies: Bağlama göre değişir. Sadece en iyi uygulamaların zor ve hızlı kuralları yoktur. Her zaman kurala ilişkin açıklamalar vardır ve bunun ne anlama gelmesini beklediğiniz anlamına gelmelidir. Yukarıdaki örnekte: GET http://example.com/dogsköpekler hakkında meta bilgiler döndürebilir (listenin kendisi değil köpekler listesi hakkında meta bilgiler). Belki ya da belki bu bir hatadır.

— Martin York,

As the last character within a URI’s path, a forward slash (/) adds no semantic value and may cause confusion. It’s better to drop them completely.

Eğitim eğik çizgi kullanmamaya işaret eden tek yer burası değil

— Laiv

@Laiv Ben duygu ile aynı fikirde değilim. Ancak, lütfen daha yetkili bir referans bağlayın (bu zayıf bir bağlantıdır).

— Martin York

Does anyone know the definitive answer?

Bir hizmetin RESTful olarak kabul edilmesi için neyin gerekli olduğuna dair resmi bir belge olmadığı için yoktur.

Bu sadece kullanım kolaylığı için sondaki eğik çizgi izin vereceğini söyledi. Teknik olarak konuşursak, bu boş kimliği olan bir köpeğe erişme girişimi olarak görülebilir; Dokümanlarınızda okumayan bir kullanıcının bu atlamayı yaptığını görmüyorum. Bir kullanıcının API'nize karşı kod yazmaya çalıştığını ve basitçe alışkanlıktan sondaki eğik çizgiyi dahil ettiğini ve köpek listesi istediklerinde neden 404 yanıtı aldıklarını merak ederek görebiliyorum.

— mikrofon
kaynak

DELETE example.com/dogs'dan ne haber ?

— Benjamin Gruenbaum

Köpekler tüm bireysel köpeklerin ebeveyni olduğundan, köpekleri silmek tüm köpekleri ve kendini siler. Bunu yapmazsanız, hiper

— ortamınız bozulur

@ Gaz_Edge: REST'te example.com/dogs, herhangi bir kaynaktan tamamen bağımsız bir kaynaktır example.com/dogs/X. Bu nedenle bir SİLME, example.com/dogstüm köpekleri / * 'yi silmek zorunda değildir (eğer bu anlamsal olsa bile). Ancak DELETE example.com/dogs/tüm köpekleri silmeli / *.

— Martin York

Bir kez daha şunu söyleyeyim, RESTful ne olduğuna dair kesin bir kurallar dizisi olmadığı için / köpekleri / köpekleri SİLİRDİĞİNİZDE ne olur, API'nizin tüketicilerinden beklentilerini beklediklerine göre. Tek bir isteği ile tüm köpekleri silmek isteyecekleri muhtemel mi? Eğer öyleyse, öyleyse öyle uygulayın, öyleyse bir 405 Yönteme İzin Verilmeyen yanıt verin.

— Mike,

Bunun eski bir konu olduğunu biliyorum, ama geçenlerde bunu merak ediyorum. İçin Ne olursa olsun, OS X Bash kabuk davranır foo, foo/ve foo////aynı şekilde. Temel olarak boş yol parçalarını çıkardığı görülmektedir. Yani, DİNLENME hizmetiyle aynı yaklaşımı izleyin eğer dogsve dogs/aynı şey bakın olur.

— Greg Brown,

İki yol.

Yöntem 1

Çocuk içerebilecek herhangi bir kaynak için her zaman sondaki eğik çizgileri kullanın.

Sadece dosyaları içeren bir public_html dizininde "GET" olarak düşünün.

Hello.html bir dosya olduğunda mümkün değildir:

/hello.html
/hello.html/youagain.html

Ancak hello.html bir dizin olduğunda mümkündür:

/hello.html/     (actually /hello.html/index.html)
/hello.html/youagain.html

Eğer "hello.html" hiç çocuk sahibi değilse, o zaman her zaman ve sonsuza kadar "/hello.html/" ve "/hello.html/index.html" (veya basitçe /hello.html/) bu çocukların bir listesidir. .

Yöntem 2

Akıllı ol".

$ find
.
./hello.html
./hello.html/index.html

Find komutu, hello.html türünü önemsemez. Dizin veya dosya, kimin umrunda, bir nesnenin adıdır. "Cp youagain.html hello.html" yazdığımızda cp, hello.html ile nasıl başedeceğinizi çözebilir. cp akıllıdır. Web sunucunuz da akıllıdır. Bir yol işleme kütüphanesine sahiptir. Yönlendirme var. İsmin bir nesne mi yoksa bir dizin mi olduğunu söyler ve söyler. Bu, filanı fiilene yönlendirebilir ve hatta her ikisi için de aynı cevabı verebilecektir. Bu harika !!! yol. Çok fazla teknoloji. Tüm bunları yapabildiğimizde kim sadece yol dizgilerini birleştirmeyi isterdi?

— Samuel Danielson
kaynak