Dinlenme Koleksiyonunda Sayfalama

JSON belgelerinin koleksiyonlarına doğrudan bir REST arayüzü göstermek istiyorum ( CouchDB veya Persevere düşünün ). Karşılaştığım sorun GET, koleksiyon büyükse koleksiyon kökündeki işlemin nasıl yapılacağıdır .

Örnek olarak, StackOverflow'un Questionstablosunu her satırın bir belge olarak gösterdiği tabloyu açığa vuruyorum (böyle bir tablo olması gerekmiyor, sadece 'belgeler'in büyük bir koleksiyonunun somut bir örneği değil). Toplama mevcut hale getirilebileceğini /db/questionszamanki CRUD API ile GET /db/questions/XXX, PUT /db/questions/XXX, POST /db/questionsoyunda. Tüm koleksiyonu almanın standart yolu şudur, GET /db/questionsancak bu her satırı bir JSON nesnesi olarak saf bir şekilde dökerse, oldukça büyük bir indirme ve sunucunun bir çok işini alırsınız.

Çözüm, elbette, çağrıdır. Dojo, JsonRestStore'daki bu sorunu , Rangebaşlığı özel bir aralık birimiyle kullanmanın akıllı RFC2616 uyumlu bir uzantısıyla çözdü items. Sonuç, 206 Partial Contentyalnızca istenen aralığı döndüren bir sonuçtur . Bir sorgu parametresine göre bu yaklaşımın avantajı, ... sorguları için sorgu dizesini GET /db/questions/?score>200bırakmasıdır (örn. Veya somesuch ve evet kodlanır %3E).

Bu yaklaşım tamamen istediğim davranışı kapsar. Sorun, RFC 2616'nın 206 yanıtta (vurgu mayın) şunları belirtmesidir:

Talep Aralık başlık alanını (içeriyor olmalıdır bölüm 14.35 ), istenen aralık ile ve varsa sınıf başlık alanını (dahil edilmiş olabilir bölüm 14.27 talep koşullu yapmak için).

Bu, başlığın standart kullanımı bağlamında mantıklıdır, ancak bir sorundur çünkü 206 yanıtın, naif istemcileri / rastgele insanları keşfetme varsayılanı olmasını istiyorum.

Bir çözüm arayan RFC'yi ayrıntılı olarak inceledim, ancak çözümlerimden memnun kalmadım ve SO'nun sorunu ele almasıyla ilgileniyorum.

Sahip olduğum fikirler:

• 200Bir Content-Rangebaşlık ile geri dönün ! - Bunun yanlış olduğunu düşünmüyorum, ancak yanıtın yalnızca Kısmi İçerik olduğunu daha açık bir gösterge olarak tercih ederim.
• Dönüş400 Range Required - Gerekli üstbilgiler için özel bir 400 yanıt kodu yoktur, bu nedenle varsayılan hatanın kullanılması ve elle okunması gerekir. Bu aynı zamanda web tarayıcısı (veya Resty gibi başka bir istemci) aracılığıyla araştırmayı zorlaştırır.
• Bir sorgu parametresi kullanın - Standart yaklaşım, ancak ben la Persevere sorgu izin vermek umuyoruz ve bu sorgu ad alanı keser.
• Sadece geri dön 206! - Bence çoğu müşteri çıldırmaz, ama RFC'de bir zorunlulukla karşı karşıya kalmamayı tercih ederim
• Spesifikasyonu uzatın! Dönüş266 Partial Content - Tam 206 gibi davranır, ancak Rangeüstbilgiyi İÇERMEMELİ bir isteğe yanıt verir . 266'nın çarpışma sorunlarıyla karşılaşmamaya yetecek kadar yüksek olduğunu ve benim için mantıklı olduğunu düşünüyorum, ancak bunun tabu olarak kabul edilip edilmediği konusunda net değilim.

Bunun oldukça yaygın bir sorun olduğunu düşünüyorum ve bunun bir çeşit fiili tarzda yapıldığını görmek istiyorum, bu yüzden ben veya başka biri tekerleği yeniden icat etmiyor.

Koleksiyon büyük olduğunda HTTP aracılığıyla tam bir koleksiyon göstermenin en iyi yolu nedir?

Bağırsak hissim, HTTP aralığı uzantılarının kullanım durumunuz için tasarlanmadığı ve bu nedenle denememeniz gerektiğidir. Kısmi bir yanıt ima edilir 206ve 206yalnızca istemci isterse gönderilmelidir.

Atom'daki tek kullanım gibi farklı bir yaklaşımı düşünmek isteyebilirsiniz (tasarım ile temsil kısmi olabilir ve bir durumla döndürülür 200ve bağlantılar potansiyel olarak sayfalanır). Bkz. RFC 4287 ve RFC 5005 .

Bazılarınızla gerçekten aynı fikirde değilim. REST servisim için haftalardır bu özellikler üzerinde çalışıyorum. Sonunda yaptığım şey gerçekten basit. Benim çözümüm yalnızca REST insanlarının koleksiyon dediği şey için bir anlam ifade ediyor.

Müşteri, koleksiyonun hangi kısmına ihtiyaç duyduğunu belirtmek için bir "Aralık" başlığı içermelidir veya istenen koleksiyon tek bir gidiş dönüş için alınamayacak kadar büyük olduğunda 413 İSTENEN ENTITY ÇOK BÜYÜK hatayı işlemeye hazır olmalıdır.

Sunucu, kaynağın hangi kısmının gönderildiğini belirten İçerik Aralığı üstbilgisi ve koleksiyonun geçerli sürümünü tanımlamak için bir ETag üstbilgisi ile 206 KISMİ İÇERİK yanıtı gönderir. Genellikle Facebook benzeri bir ETag {last_modification_timestamp} - {resource_id} kullanıyorum ve bir koleksiyonun ETag değerinin içerdiği en son değiştirilen kaynağın olduğunu düşünüyorum.

Bir koleksiyonun belirli bir bölümünü istemek için, istemcinin "Aralık" üstbilgisini kullanması ve "If-Match" üstbilgisini, aynı koleksiyonun diğer bölümlerini edinmek için önceden gerçekleştirilen isteklerden elde edilen koleksiyonun ETag'i ile doldurması GEREKİR. Bu nedenle sunucu, istenen bölümü göndermeden önce koleksiyonun değişmediğini doğrulayabilir. Daha yeni bir sürüm varsa, istemciyi koleksiyonu sıfırdan almaya davet etmek için bir 412 PRECONDITION FAILED yanıtı döndürülür. Bu gereklidir, çünkü şu anda istenen bölümden önce veya sonra bazı kaynakların eklenmiş veya kaldırılmış olabileceği anlamına gelebilir.

Önbelleği en iyi duruma getirmek için ETag / If-Match'i Last-Modified / If-Mododified-Since ile birlikte kullanıyorum. Tarayıcılar ve proxy'ler önbellek algoritmaları için bunlardan birine veya her ikisine güvenebilir.

Ben bir arama / filtre sorgusu içermez sürece bir URL temiz olması gerektiğini düşünüyorum. Bunu düşünürseniz, arama bir koleksiyonun kısmi görünümünden başka bir şey değildir. Arabalar / arama? Q = BMW türü URL'ler yerine daha fazla araba? Üreticisi = BMW görmeliyiz.

Hala dönebilir Accept-Rangesve Content-Rangesbir ile 200yanıt kodu. Bu iki yanıt başlıkları size yeterince bilgi vermek çıkarımda bir aynı bilgileri 206yanıt kodu açıkça sağlar.

Ben Rangesayfalandırma için kullanmak ve sadece 200bir düz için bir dönüş var GET.

Bu% 100 RESTful hissediyor ve taramayı daha da zorlaştırmıyor.

Düzenleme: Bununla ilgili bir blog yazısı yazdım: http://otac0n.com/blog/2012/11/21/range-header-i-choose-you.html

Birden fazla yanıt sayfası varsa ve tüm koleksiyonu aynı anda sunmak istemiyorsanız, bu birden fazla seçenek olduğu anlamına mı geliyor?

Bir İstek üzerine /db/questionsdönüş, 300 Multiple Choicesile LinkURL'lerin listesini her sayfasının yanı sıra bir JSON nesnesi veya HTML sayfasına gitmek için nasıl belirtmek başlıklarını.

Link: <>; rel="http://paged.collection.example/relation/paged"
Link: <>; rel="http://paged.collection.example/relation/paged"
...

LinkHer sonuç sayfası için bir üstbilginiz olur (boş bir dize, geçerli URL anlamına gelir ve URL, her sayfa için aynıdır, yalnızca farklı aralıklarla erişilir) ve ilişki, sonraki Linkspesifikasyonlar için özel bir tanımlı olarak tanımlanır . Bu ilişki geleneğinizi 266veya ihlalinizi açıklar 206. Bu üstbilgiler, makine tarafından okunabilen sürümünüzdür, çünkü tüm örnekleriniz zaten bir anlayış istemcisi gerektirir.

(Eğer "aralık" yoluna sadık kalırsanız, kendi 2xxdönüş kodunuzun, açıkladığınız gibi, burada en iyi davranış olacağını düşünüyorum. Bunu uygulamalarınız için yapmanız bekleniyor ve bu tür ["HTTP durum kodları genişletilebilir. "] ve iyi nedenleriniz var.)

300 Multiple Choicesayrıca, bir kuruluşa kullanıcı aracısının seçmesi için bir yol sağlamanız GEREKİR. Müşteriniz anlıyorsa, Linkbaşlıkları kullanmalıdır . Bir kullanıcı manuel olarak geziniyorsa, URL'ye dayalı olarak söz konusu sayfanın oluşturulmasını işleyebilecek özel bir "disk belleği" kök kaynağına bağlantılar içeren bir HTML sayfası olabilir mi? /humanpage/1/db/questionsya da böyle iğrenç bir şey mi?

Richard Levasseur'un gönderisine ilişkin yorumlar bana ek bir seçeneği hatırlatıyor: Acceptbaşlık (bölüm 14.1). OEmbed spesifikasyonu ortaya çıktığında, neden tamamen HTTP kullanılarak yapılmadığını merak ettim ve bunları kullanarak bir alternatif yazdım.

Tutun 300 Multiple Choices, Linkbir başlangıç naif HTTP için başlıkları ve HTML sayfası GETdeğil, kullanım aralıkları daha yeni sayfalama ilişki kullanımını tanımlamak zorunda Acceptbaşlığındaki. Sonraki HTTP isteğiniz şöyle görünebilir:

GET /db/questions HTTP/1.1
Host: paged.collection.example
Accept: application/json;PagingSpec=1.0;page=1

AcceptBaşlık Eğer bu tür (senin sayfa numarası) için kabul edilebilir bir içerik türü (JSON dönüş), artı genişletilebilir parametrelerini tanımlamak için izin verir. OEmbed yazımdaki notlarıma dayanarak (buraya bağlanamıyorum, profilimde listeleyeceğim), çok açık olabilir ve pageparametrenin ne anlama geldiğini yeniden tanımlamanız gerektiğinde burada bir spec / ilişki sürümü sağlayabilirsiniz gelecekte.

Düzenle:

Biraz daha düşündükten sonra, Range başlıklarının sayfalandırma için uygun olmadığını kabul etmeye meyilliyim. Mantık, Range başlığı uygulamalar için değil sunucunun yanıtı için tasarlanmıştır. 100 megabayt sonuç verdiyseniz, ancak sunucu (veya istemci) bir seferde yalnızca 1 megabayt işleyebildiyse, aralık başlığının nedeni budur.

Ayrıca, bir kaynak alt kümesinin kendi kaynağı (ilişkisel cebire benzer) olduğu kanaatindeyim, bu yüzden URL'de temsili hak ediyor.

Temel olarak, bir başlık kullanma hakkındaki orijinal cevabımı (aşağıda) tekrar okuyorum.

Sanırım kendi sorunuzu az çok cevapladınız - içerik aralığı ile 200 veya 206 döndürün ve isteğe bağlı olarak bir sorgu parametresi kullanın. Kullanıcı aracısını ve içerik türünü kokluyorum ve bunlara bağlı olarak bir sorgu parametresi kontrol ediyorum. Aksi takdirde, aralık başlıklarını isteyin.

Temelde çelişkili hedefleriniz var - insanların tarayıcılarını keşfetmek için kullanmasına izin verin (bu, özel başlıklara kolayca izin vermez) veya insanları başlık ayarlayabilen (keşfetmelerine izin vermeyen) özel bir müşteri kullanmaya zorlayın.

Onlara isteğe bağlı olarak özel istemci sağlayabilirsiniz - düz bir tarayıcıya benziyorsa, sayfayı oluşturan ve gerekli başlıkları ayarlayan küçük bir ajax uygulaması gönderin.

Elbette, URL'nin bu tür bir şey için gerekli tüm durumu içermesi gerekip gerekmediğine dair tartışmalar da vardır. Başlıkları kullanarak aralığın belirtilmesi, bazıları tarafından "rahat" olarak değerlendirilebilir.

Bir yana, sunucuların "Can-Specify: Header1, header2" üstbilgisi ile yanıt verebilmesi hoş olurdu ve web tarayıcıları kullanıcıların istedikleri takdirde değerleri girebilmeleri için bir kullanıcı arayüzü sunacaktır.

Atom Besleme Protokolü gibi bir modeli bir model kullanmayı düşünebilirsiniz çünkü koleksiyonların aklı başında bir HTTP modeli ve bunların nasıl işleneceği (delilik WebDAV anlamına gelir).

Orada Atom Yayıncılık Protokolü toplama modelini ve DİNLENME operasyonlarını tanımlar artı kullanabilirsiniz RFC 5005 - Yem Çağrı ve Arşivleme büyük koleksiyonlara göz sayfaya.

Atom XML'den JSON içeriğine geçmek fikri etkilememelidir.

Buradaki asıl sorun, spesifikasyonda bize 413 - Talep Edilen Varlık Çok Büyük ile karşılaşıldığında otomatik yönlendirmelerin nasıl yapılacağını söyleyen hiçbir şey olmamasıdır.

Son zamanlarda aynı problemle uğraşıyordum ve RESTful Web Services kitabında ilham aradım . Kişisel olarak başlık gerekliliği nedeniyle 206'nın uygun olduğunu düşünmüyorum. Düşüncelerim beni 300'e getirdi, ancak bunun farklı mim türleri için daha fazla olduğunu düşündüm, bu yüzden Richardson ve Ruby'nin Ek B, sayfa 377'deki konu hakkında ne söylediklerine baktım. Sunucunun sadece ve bir 200 ile geri gönderin, temelde 300 olması gerektiği fikrini göz ardı ederek.

Bu aynı zamanda atomdan sahip olduğumuz bir sonraki kaynaklara bağlantılar fikrine de atlar. Uyguladığım çözüm, geri gönderdiğim json haritasına "sonraki" ve "önceki" anahtarları eklemek ve onunla yapılmasıydı.

Daha sonra düşünmeye başladım, belki de yapılacak şey, / db / sorular / 1,25 gibi bir şey olacak bir bağlantıya 307 - Geçici Yönlendirme göndermek ve orijinal URI'yı kanonik kaynak adı olarak bırakıyor, ancak sizi uygun şekilde adlandırılmış bir alt kaynak. Bu 413 kişiden görmek istediğim bir davranış, ama 307 iyi bir uzlaşma gibi görünüyor. Aslında bunu henüz kodda denemedim. Daha da iyisi, yönlendirmenin en son sorulan soruların gerçek kimliklerini içeren bir URL'ye yönlendirmesi. Örneğin, her sorunun bir tamsayı kimliği varsa ve sistemde 100 soru varsa ve en son on soruyu göstermek istiyorsanız, / db / sorular için istekler / db / sorular / 100,91

Bu çok iyi bir soru, sorduğunuz için teşekkürler. Günlerimi düşünerek geçirdiğim için deli olmadığımı doğruladın.

RangeBaşlığı algılayabilir ve varsa Dojo'yu taklit edebilir ve yoksa Atom'u taklit edebilirsiniz. Bana öyle geliyor ki bu kullanım durumlarını düzgün bir şekilde bölüyor. Bir REST sorgusunu uygulamanızdan yanıtlıyorsanız, bu sorgunun bir Rangebaşlıkla biçimlendirilmesini beklersiniz . Sıradan bir tarayıcıya yanıt veriyorsanız, sayfalama bağlantılarını döndürürseniz, aracın koleksiyonu keşfetmenin kolay bir yolunu sağlar.

Aralık başlıkları ile ilgili büyük sorunlardan biri, birçok kurumsal vekillerin bunları filtrelemesidir. Bunun yerine bir sorgu parametresi kullanmanızı öneririm.

Rfc723x'in yayınlanmasıyla birlikte , kayıt dışı menzil birimleri spesifikasyonda açık bir tavsiyeye karşıdır . Rfc7233'ü (rfc2616'dan vazgeçerek) düşünün :

" Yeni aralık birimleri IANA'ya kayıtlı olmalıdır " (bir HTTP Aralık Birimi Kaydı referansı ile birlikte ).

Bana öyle geliyor ki bunu yapmanın en iyi yolu aralığı sorgu parametreleri olarak eklemektir. örneğin, GET / db / sorular /? tarih> mindate ve tarih <maxdate . / Db / sorular / için bir sorgu parametresi olmadan bir GET üzerine 303 konum: / db / sorular /? Sorgu-parametreleri-almak-varsayılan-sayfasına döndürün . Ardından, koleksiyon hakkında istatistik almak için API'nızı kimin tükettiği farklı bir URL sağlayın (ör. Koleksiyonun tamamını istiyorsa hangi sorgu parametrelerinin kullanılacağı);

Range başlığını bu amaçla kullanmak mümkün olsa da, bunun niyet olduğunu düşünmüyorum. Kesintili bağlantıları işlemek ve verileri sınırlamak için tasarlanmış gibi görünüyor (böylece istemci bir şey eksikse veya boyut işlenemeyecek kadar büyükse isteğin bir kısmını isteyebilir). İletişim katmanında başka amaçlarla kullanılan bir şeye sayfa numaralandırmayı kesiyorsunuz. Sayfalandırmayı ele almanın "uygun" yolu, döndürdüğünüz türlerdir. Soru nesnesini döndürmektense, bunun yerine yeni bir tür döndürmeniz gerekir.

Sorular böyle ise:

<questions> <question index=1></question> <question index=2></question> ... </questions>

Yeni tür şöyle olabilir:

<questionPage> <startIndex>50</startIndex> <returnedCount>10</returnedCount> <totalCount>1203</totalCount> <questions> <question index=50></question> <question index=51></question> .. </questions> <questionPage>

Tabii ki medya türlerinizi kontrol edersiniz, böylece "sayfalarınızı" ihtiyaçlarınıza uygun bir format haline getirebilirsiniz. Genel bir şey yaparsanız, istemcide tüm türler için aynı sayfalamayı işlemek için tek bir ayrıştırıcıya sahip olabilirsiniz. Bu, Range parametresini başka bir şey için yumuşatmak yerine HTTP spesifikasyonunun ruhunda daha fazla olduğunu düşünüyorum.