Özyinelemeli bir kaynak için en iyi RESTful URL yapısı nedir?

Bir ağaç benzeri kaynak yapısı için bir RESTfull hizmet oluşturuyorum ve en iyi URL yapısının ne olacağını merak ediyordum?

Üç gereksinimim var:

kök kaynaklardan bir koleksiyon elde edebilme
Bireysel bir kaynak elde edebilmek
çocuk kaynakları koleksiyonunu elde edebilme

Şu anki düşüncem:

/rest/documents
/rest/documents/{id}
/rest/documents/{id}/documents

Ayrıca listeleri veya tek tek öğeleri belirtmek için tekil / çoğul yollar gitmeyi düşünüyordum, ancak tekil olduğu gibi aynı çoğul olan bir kaynağa sahip olacağımı biliyorum, buna karşı karar verdim.

Yukarıdakiler hakkında herhangi bir fikri olan var mı? ya da bunu yapılandırmanın farklı / daha iyi bir yolu var mı?

web-services

— Matt Brailsford
kaynak

Soruyu yanlış anlayabilirim ama URL'lerden bahsederken SEO bir sorun mu?

— Jon Hopkins

SEO bir sorun değil, hayır. Temelde bir kendini referanslama kaynağı için en iyi mantıksal URL yapısını soruyorum.

— Matt Brailsford

Bu benim için oldukça basit görünüyor.

— Tim Post

Bu yapı ne kadar derine inebilir?

— Martijn Verburg

@Martijn derinlik sınırlandırılmamış

— Matt Brailsford

Yanıtlar:

Aklıma gelen şey: RESTful API URL'sinin özyinelemesini yansıtmanıza izin vermeyin. Bir düşünün, kaynağınız sadece belgeler.

Belgelerinizi özyinelemeli yapıya göre fiziksel olarak depoladıysanız, benzersiz bir kimliğe eşleme oluşturun ve URL'deki kimliği kullanın:

/rest/documents/{id}

Şimdi, belgeleriniz böyle varsa:

| BelgeAdı | DocumentPath | Belge Kimliği |
--------------------------------------------
| abc | / abc | 1 |
| asd | / abc / asd | 2 |
| asd | / asd | 3 |
| boo | / abc / asd / boo | 4 |
| hey | / abc / asd / hey | 5 |

istek /abc/asdbelge için bu URL'ye başvurur

GET /rest/documents/2

Şimdi, API'nızın kullanıcılarına yapınızı az çaba sarf etmek için araçlar sağlamanız gerekiyor. Bu, yanıt yükünüzü (belge) aşağıdaki gibi ek geçiş bilgileri içeren bir nesneye sararak yapılabilir:

{
   data: { /* your document goes here */ },
   parent: {"abc": 1 },
   children: [ { "boo": 4 }, { "hey": 5} ]
}

kullanıcıların tek bir düzeyde çok fazla belge oluşturmamasını beklediğiniz takdirde, yanıta bir çocuk listesi ekleyebilirsiniz. Böyle bir durum söz konusu değilse, kullanıcıya, sonuçların sorgu dizesi parametreleri aracılığıyla sayfalanmasına izin vererek, bu şekilde alt belge kimliklerini almasını önerebilirsiniz:

GET /rest/documents/2/children?page=2&size=50

Son olarak, querystring parametrelerinden bahsetmişken, yol bilgisini doğrudan querystring parametreleri aracılığıyla da sağlayabilirsiniz:

GET /rest/documents?path=somepath&page=1&size=42

Bahsedilen tüm yaklaşımlar ovanın GET /rest/documentssadece kök belgeleri döndürmesini beklemektedir .

— netchkin
kaynak

İyi bir fikir. Ancak, alt dokümanlar bir dokümanın yanıtına dahil edilirse alt dokümanlar ile olan ilişki API'dan net değildir. Belgelerde başka yorumlar da varsa, örneğin yorumlar varsa, normalde / belgeler / {id} / sorular kullanarak bir belgenin sorularına erişirsiniz. Tutarlı olmak ve API'da alt belgelere olan ilişkiyi netleştirmek için alt belgelere / belgeler / {id} / alt belgelerden erişilmesi gerektiğini öneririm. Döndürülen temsiller, / belgeler / {id} gibi Dokümanlar olacaktır. Yani, burada tarif ettiklerinizin geri kalanı hala çalışıyor.

— Nathan Ward

Belki böyle bir şey:

/rest/{rootEntity}/Item/{leafEntity}/{id}
/rest/{entity}/ItemList
/rest/{entity}/ItemList/{leafEntity}

burada {rootEntity} koleksiyonunuzun başlangıç noktasıdır, {leafEntity} ağacınızdaki herhangi bir adlandırılmış yaprak düğümüdür.

En son veya Tümü veya başka bir şey seçmek için yukarıdakilerden herhangi birini birkaç parametre ekleyebilirsiniz.

— Gary Rowe
kaynak