search

OParl / spec

Spezifikation für eine offene Schnittstelle für Ratsinformationssysteme
https://oparl.org
Creative Commons Attribution Share Alike 4.0 International
61 stars 21 forks source link

Paging per http Link header (war: http ranges statt paging) #135

Closed akuckartz closed 10 years ago

akuckartz commented 10 years ago

Statt der Aufteilung größerer Datenmengen auf JSON-LD oder OParl-Ebene (wo sie ein Fremdkörper ist) kommt eventuell die Verwendung klassischer http-Mechanismen in Frage.

akuckartz commented 10 years ago

@marians Ich schlage einen Verzicht auf die OParl-Paging-Konstruktionen und stattdessen die Verwendung der in HTTP 1.1 für den Abruf/die Übertragung großer Dateien vorgesehenen Mechanismen vor.

Siehe: http://en.wikipedia.org/wiki/Byte_serving

marians commented 10 years ago

Mir ist keine Webservice API bekannt, die das so macht. Würde ich daher nicht als Best Practise bezeichnen.

Aufteilung von Listen in chunks findet man in vielen Webservice APIs und kennt man von Datenbank-Schnittstellen und SQL. Ich sehe nicht, wie sowas in der OParl API ein Fremdkörper ist.

Ich möchte am Listen-Konstrukt festhalten, als bislang IMHO bessere Option.

akuckartz commented 10 years ago

Bisherige Webservice APIs sind ja gerade das Problem ;-)

Ausserhalb dieser Paging-Dinge gibt es gegenwärtig erfreulicherweise fast nichts in OParl, was eine API wäre - weshalb ich die Charakterisierung von OParl als "API" auch für nicht korrekt halte.

Wir haben ein Standard-Protokoll (http 1.1) und ein Standard-Format (JSON-LD), ein Vokabular und ein paar Konventionen zu deren Verwendung. Ein Client soll deshalb idealerweise nichts mit Paging zu tun haben müssen. Wenn wir dem Client die Alternative einräumen, die Daten vom Server in einem Rutsch (oder per http in Einzelstücken) zu erhalten, dann ist das für mich auch ok.

Nebenbei: Die Diskussionen hierzu sind interessant (das wird so bald nicht fertig werden):

Linked Data Platform Paging 1.0 https://dvcs.w3.org/hg/ldpwg/raw-file/default/ldp-paging.html

marians commented 10 years ago

Hier ist noch eine Alternative, die ich klug finde.

Sie wird beispielsweise auf http://envirocar.github.io/enviroCar-server/api/ unter "Pagination" beschrieben.

Es geht darum, im HTTP Response per Header die URLs zu weiteren Ergebnisseiten zu kommunizieren. Beispiel:

Link: <https://envirocar.org/api/stable/measurements?limit=2&page=1>;rel=first;type=application/json
Link: <https://envirocar.org/api/stable/measurements?limit=2&page=19>;rel=prev;type=application/json
Link: <https://envirocar.org/api/stable/measurements?limit=2&page=21>;rel=next;type=application/json
Link: <https://envirocar.org/api/stable/measurements?limit=2&page=4169>;rel=last;type=application/json

Mittels "rel=next" etc. wird erklärt, was der Link tut. Das richtet sich nach RFC5988 (http://tools.ietf.org/html/rfc5988).

Bisher finde ich das favorisierenswert.

akuckartz commented 10 years ago

@marians Ja, Paging über http-Header zu behandeln ist generell eine Möglichkeit. Ich mache mir in den nächsten Tagen Gedanken darüber was eventuell dagegen spricht und ob/wie das zu den W3C LDP Paging Plänen passt.

akuckartz commented 10 years ago

@marians Der W3C LDP Paging Entwurf stützt sich ebenfalls auf RFC 5988. Das spricht also tendentiell für eine solche Lösung. Ich habe mir deshalb auch kurz den Stand von LDP Paging weiter angesehen: https://dvcs.w3.org/hg/ldpwg/raw-file/default/ldp-paging.html#atrisk-333

Möglicherweise können ein paar Detail-Lösung daraus auch für OParl Paging verwendet werden. Alle auf keinen Fall, da ein paar Features als "at risk" deklariert sind und neue http status codes gewünscht werden, was auch von der IETF abhängt. Gut ist, dass in diese Paging-Spezifikation viel Arbeit und Expertise rein gesteckt wird - nicht nur von IBM und Oracle. Gleichzeitig hält sich die Komplexität in Grenzen.

akuckartz commented 10 years ago

Ich habe mir das genauer angesehen und bin jetzt auch für Paging per Link Header. Das dürfte insgesamt die beste Lösung sein, denn es:

marians commented 10 years ago

Super. Ich kann anbieten, das heute einzubauen. Soll ich?

akuckartz commented 10 years ago

@marians Ja, gerne.

marians commented 10 years ago

Habe das Kapitel (aktuell 4.8.2) nun überarbeitet. In Kürze:

Ich schließe das Issue. Wie immer: Wieder öffnen, wenn nötig.