Issue 18126

return 304 if resource hasn't changed.

18126
Reporter: hoefft
Assignee: cgendreau
Type: NewFeature
Summary: return 304 if resource hasn't changed.
Priority: Major
Resolution: Done
Status: Done
Created: 2016-01-06 16:36:57.317
Updated: 2016-04-06 15:20:29.753
Resolved: 2016-04-06 15:20:29.749
        
Description: The client is slow because we fetch all (the relevant) data every time a page is visited.
It makes sense to not cache much on the client as the user needs to be notified of changes. But fetching the full dataset every time the user navigates to the people table is expensive.

I see 3 solutions:

It would be very nice if the server only served data when something had changed. The client seems slow otherwise. That is returning 304.

Alternatively we could cache in the client and the bust now and then. But it seems like a better solution to do so on the server.

A last solution could be to only load a few results at a time, but then the server must support search and pagination. And the client have to be rewritten to use that instead.]]>
    


Author: fmendez@gbif.org
Comment: [~hoefft] basically all the services support pagination, full text search is not supported by the web services....however we can consider removing such functionality if it wasn't explicitly requested or else implement it at the ws level
Created: 2016-01-07 16:28:35.042
Updated: 2016-01-07 16:28:35.042


Author: hoefft
Created: 2016-01-08 09:56:28.268
Updated: 2016-01-08 09:56:28.268
        
[~fmendez@gbif.org] we need search. Else finding things is too cumbersome. Currently i do pagination, sorting and searching in the client. I know that the ws supports pagination, but without the other features it isn't really useful. But I think the client version will perform fine if we trim the response down to the relevant fields and stop including everything including nested relations.
Nodes and Participant for example perform well. Even on mobile. And so does people once the data is fetched. The problem is the size of the data and the fact that it doesn't return 304 when nothing has changed. Fixing those 2 things will make it much faster.

That said we could also try the other solutions, I just imagine that these two is the simplest. Especially because they would be nice to implement either way. 
    


Author: cgendreau
Created: 2016-04-06 15:20:27.04
Updated: 2016-04-06 15:20:27.04
        
304 is now returned of all 'list' operations.
'list' is a GET on the resource root e.g. /participant (with no id)