Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

HTTP Status Code bei Zugriff auf erste Paging-Seite #147

Closed
akuckartz opened this issue May 11, 2014 · 8 comments
Closed

HTTP Status Code bei Zugriff auf erste Paging-Seite #147

akuckartz opened this issue May 11, 2014 · 8 comments

Comments

@akuckartz
Copy link
Contributor

Im W3C LDP Paging Draft gibt es in der Vorbemerkung "Feature at Risk" zu 5.2.2.6 Hintergrund-Informationen dazu:
https://dvcs.w3.org/hg/ldpwg/raw-file/default/ldp-paging.html#ldpr-Paging

Gegenwärtig kann der dort neu vorschlagene Status Code 333 ("Returning Related") noch nicht verwendet werden, da er erst durch W3C und IETF beschlossen werden muss. 303 ("See Other") geht aber auch, der Unterschied ist gering.

@akuckartz akuckartz added this to the 1.0 Entwurf milestone May 11, 2014
@akuckartz akuckartz self-assigned this May 11, 2014
@marians
Copy link
Contributor

marians commented May 12, 2014

Was spricht denn bei der aktuellen Form der Umsetzung mit Link-Header gegen einen 200er Status?

@akuckartz
Copy link
Contributor Author

@marians HTTP Status Code 200 ("OK") signalisiert, dass der Request im Body vollständig beantwortet ist, was aber nicht stimmt, wenn nur eine Teillieferung (eine Seite) erfolgt ist.

HTTP Status Code 206 "Partial Content" geht auch nicht, das das für Content-Range reserviert ist.

@marians
Copy link
Contributor

marians commented May 12, 2014

Da gibt es einen Interpretationsspielraum. Ich finde, wenn der Server die Anfrage an eine Liste mit der Auslieferung der ersten N Einträge der Liste beantwortet, ist das im Sinne der OParl API völlig OK. Der OParl-Client weiß, dass er auf einen eventuell gesendeten Link-Header zu achten hat.

Für Oparl 1.0 finde ich das jedenfalls vollkommen ausreichend.

@akuckartz
Copy link
Contributor Author

Ich sehe den Interpretationsspielraum nicht. (Vor allem, weil hier kein Bedarf für eine weite Interpretation besteht.)

@akuckartz
Copy link
Contributor Author

Der Einfachheit halber: ich mache einen Vorschlag dazu. (Ich hatte mir das Issue zugewiesen.)

@marians
Copy link
Contributor

marians commented Jun 25, 2014

Ich wiederhole noch mal, dass ich Status Code 200 absolut in Ordnung und richtig finde. Clients werden den Status Code nicht benötigen, um festzustellen, dass eine Liste zwecks Pagination verkürzt ausgegeben wurde, denn dafür gibt es andere eindeutige Merkmale.

Auch sehe ich nicht, dass sich hier sonst jemand beteiligt. Ich vermute daher, dass das für 1.0 keine Relevanz hat und ändere die Milestone-Zuordnung und das Tagging.

@akuckartz
Copy link
Contributor Author

Bei Umsetzung von #172 (comment) kann dieses Issue geschlossen werden.

@akuckartz akuckartz removed their assignment Jun 30, 2014
@marians
Copy link
Contributor

marians commented Jul 8, 2014

Lösung im Dokument sieht nun vor, auch bei paginierten Listen den HTTP-Status-Code 200 zu verwenden.

@marians marians closed this as completed Jul 8, 2014
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Development

No branches or pull requests

2 participants