Issue 14707

Select fields to return across API methods?

14707
Reporter: feedback bot
Type: NewFeature
Summary: Select fields to return across API methods?
Priority: Minor
Status: Open
Created: 2014-01-15 16:35:40.623
Updated: 2014-04-22 18:00:37.083
        
        
Description: Hello,

Would it be possible to allow field selection on API calls?  For example, instead of getting all fields back for each occurrence this call

http://api.gbif.org/v0.9/occurrence/search?taxonKey=1&fl=latitude,longitude

would return only the latitude and longitude fields.  It is not a big deal to get all fields back with small calls, but when requesting a large amount of data, limiting the fields to those needed would be especially useful.

Cheers,
Scott Chamberlain

*Reporter*: Scott Chamberlain
*E-mail*: [mailto:scott@ropensci.org]]]>
    


Author: kbraak@gbif.org
Comment: [~bko@gbif.org] also mentioned yesterday it would be great to just get back the key/occurrenceID for example. 
Created: 2014-01-16 12:33:31.962
Updated: 2014-01-16 12:33:31.962


Author: mdoering@gbif.org
Created: 2014-01-16 13:37:07.523
Updated: 2014-01-16 13:37:07.523
        
We could do, but performance wont get much better as we have to read the whole thing anyway.
The only alternative brief format I would consider is returning only the occurrence ids - that would be extremely quick. But Im not sure if that really is useful to anyone.
    


Author: bko@gbif.org
Created: 2014-01-16 14:57:21.49
Updated: 2014-01-16 14:57:21.49
        
I assume returning occurrenceID will also allow that to be seen on the portal occurrence record page and API, which is what data publishers expect to see if they've made efforts to generate unique ID and map it to occurrenceID.

I think the original request make sense to API users. Although we have to read the whole thing anyway, returning only what is needed means less bandwidth for API users. So they can build more efficient app and that will in return benefit us.
    


Author: mdoering@gbif.org
Comment: But it will cost us a significant overhead of building this flexibility. We generate JSON automatically based on java classes right now. Changing to a flexible output model would mean quite some work. Returning the GBIF! occurrence ids (not the publisher provided occurrence ids) alone could be serialized automatically also, but anything else I would put on the backlog of our tasks and make this low priority.
Created: 2014-01-16 15:21:12.288
Updated: 2014-01-16 15:21:12.288


Author: bko@gbif.org
Comment: I think it's understandable that we manage priority and get back to this later.
Created: 2014-01-16 15:25:21.885
Updated: 2014-01-16 15:25:21.885