matzew wrote: since the pipe (or the paging request) knows whether the paging information is sent as headers, as query parameters, or as body data, it would just "serialize" the give "param provider" into the actual location.
from me: This is the part I don't understand so sorry if I'm the only one being dense here. I believe that is basically what we decided to do yesterday, but, without that initial config, how do I make the initial request for the first page? Since the callback that the dev would provide isn't triggered until a successful read so that it can "build" the next/prev methods based on the response, how do I make that first request?
Looking at the spec we do specify a
pagingLocation
argument (see summers email) somewhere (on the pipe or on the read. I don't care... -> imo NOT that important, it's a minimal diff, just from where to read).So, the pipe (or the "paging request" (the readWithFilter in Java land......)) knows where to put the paging information (for instance: a regular query, part of the body or even on the header. According to summers email, Kris and summer decided that).
Now..... at the end of the day "http params" work just like a map/dictionary (key=value). It should be very easy to give the underlying http client (jQuery, AFNetworking or whatever) a map of parameters and their values), and it appends them to the desired location (I am referencing the agreement from last night, on IRC).
So,... if the user has 15 parameters to be provided to a "pagination API", the current design does NOT allow that... (looking here: https://gist.github.com/4558860).
Instead, if we give the user an "API" (parameter provider), he can set the paging parameters, like: