NetTalk Central

Author Topic: REST: GET Collection pagination reponse  (Read 3829 times)

Poul

  • Full Member
  • ***
  • Posts: 160
    • View Profile
REST: GET Collection pagination reponse
« on: September 29, 2016, 02:27:57 PM »
When one does a REST request like  "GET /myservice/orders" all the rows in the collection can be returned.
the result can be quite large so, the Result needs to be paged, I do not see anything baked in..

Some research has me considering some 'standard approaches' but before i start coding,
it seems that Nettalk may already have or certainly would benefit from a standard  (perhaps NT friendly or optimized) approach
that facilitates clients (especially NT clients)  easily consuming NT REST services.

I know there is recent activity in syncing data ("Beyond SQL..."), but are there any plans/suggestions/hooks/examples or must one roll their own?
I am thinking of filters on the url,  - with the paging state values in metadata in the HEADERS and/or BODY of a RESTful  response.

poul



Bruce

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 11250
    • View Profile
Re: REST: GET Collection pagination reponse
« Reply #1 on: October 11, 2016, 11:26:44 PM »
Hi Poul,

>> The result can be quite large so, the Result needs to be paged,

well... in one sense no, the result can be enormously large if the request was for a lot of data.
On the other hand it's likely useful for you to add filtering parameters which allow the client to fetch a subset of data.
(like say the data for one date, or all employees with the name starting with xxx).

>> I do not see anything baked in..

Other than letting you specify the filter, no.

>> Some research has me considering some 'standard approaches' but before i start coding,
>> It seems that Nettalk may already have or certainly would benefit from a standard  (perhaps NT friendly or optimized)
>>approach that facilitates clients (especially NT clients)  easily consuming NT REST services.

I think the approach will be completely dependent on the data itself. Some might be paged by time, some might be limited to something alphabetic, some might be based on a number (like invoice numbers.) I've seen cases where it's done on "data changed since...". It's going to be very different from one table to the next.

Probably the least useful approach is "page number". The key for that would be very specific (things are always added in "page order?") Plus it would be very difficult for an app to get a specific bit of data, like a specific employee or specific invoice etc.

>> I know there is recent activity in syncing data

This uses a "changed time stamp" approach, and allows you to fetch data which was "changed since the last time I fetched". For syncing where you want "everything that has changed" this makes good sense.

cheers
Bruce