Pagination sollte in der API überall einheitlich implementiert sein

[funkenstrahlen]

Aktuell kann ich Pagination noch nicht wirklich nutzen, da manche Requests das unterstützen, andere aber nicht.

Das müsste dann aber in einer Version 3 der API landen, weil das ein Breaking Change ist.

[eazyliving]

So ist es. Das erste Thema für die 0.3.

[eazyliving]

Ich sammle mal ein, welche requests das aktuell betrifft. Die Frage, die sich mir stellt: Mache ich das wirklich für alle requests oder nur für die, wo es auch sinnvoll ist/erscheint? Ersteres wäre anfangs mehr Arbeit und bei einzelnen, komplizierten requests mehr Arbeit in der Implementierung. Letzteres wäre insgesamt weniger Arbeit, aber anfällig für "huch, hab ich vergessen"...

In dieser Liste findet sich jetzt das Zeug, das ich als sinnvoll erachte:

GET /user/curations[/episodes]
GET /user/collections[/podcasts]
GET /action
GET /podcast/recommend
GET /podcast/latest
GET /curation[/episodes]
GET /category/curation
GET /collection[/podcasts]
GET /search/episode
GET /search/podcast
GET /search/curation
GET /search/user

[funkenstrahlen]

Ja ich denke grundsätzlich hast du schon Recht das nur für Requests zu machen bei denen das Sinn macht. Nach welchen Kriterien hast du die denn nun ausgewählt?

Es gibt aber auch APIs, die das einfach grundsätzlich für alle Requests machen, damit das einheitlich ist. Bei den Requests bei denen das (eigentlich) nicht nötig ist, gibt es dann eben nur eine Page.

Was am Ende das richtige Modell ist kann ich aber auch nicht sagen. Wirklich Fachmann bin ich dafür nicht.