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