Okay, thanks for the update. Scott
On Thu, Feb 8, 2018 at 1:33 PM Markus D?ring <mdoering at gbif.org> wrote: > Yes Scott, they all accept just one value. > The only exception is actually datasetKey if it is used together with a > name parameter. In that case only a set of dataset keys is allowed. Not > exactly intuitive, but thats how the interface was designed: > > PagingResponse<NameUsage> list(Locale locale, UUID datasetKey, String > sourceId, Pageable page); > > PagingResponse<NameUsage> listByCanonicalName(Locale locale, String > canonicalName, Pageable page, UUID ... datasetKey); > > Markus > > > > On 8. Feb 2018, at 19:28, Scott Chamberlain <myrmecocystus at gmail.com> > wrote: > > > > Hi Markus, > > > > Thanks very much for your help on this. That seems like a good solution. > > > > Does the only 1 instance of a parameter per request apply to the other > parameters on that route as well? > https://www.gbif.org/developer/species#nameUsages name, sourceId, > language > > > > Best, Scott > > > > On Thu, Feb 8, 2018 at 2:11 AM Markus D?ring <mdoering at gbif.org> wrote: > > Hi again, > > > > I just checked code and it was done intentionally as our API interface > is defined for all or just one dataset key: > > > https://github.com/gbif/gbif-api/blob/master/src/main/java/org/gbif/api/service/checklistbank/NameUsageService.java#L82 > > > > I propose to throw an IllegalRequest in case of more than one datasetKey > for the time being. > > If you want this to be changed please log an API issue or enhancement > request in the portal. > > > > Cheers, > > Markus > > > > > On 8. Feb 2018, at 11:04, Markus D?ring <mdoering at gbif.org> wrote: > > > > > > Hi Scott, > > > indeed it only picks up one of the parameters. Looks like an oversight > and probably one that is existing elsewhere too then ;) > > > Ive logged an issue: https://github.com/gbif/checklistbank/issues/54 > > > > > > Markus > > > > > > > > > > > >> On 7. Feb 2018, at 22:37, Scott Chamberlain <myrmecocystus at gmail.com> > wrote: > > >> > > >> Hi folks, > > >> > > >> Seems like the `/species` route is possibly misbehaving in certain > cases. A user of rgbif reports > https://github.com/ropensci/rgbif/issues/287 unexpected results. The same > calls but with curl: > > >> > > >> curl ' > https://api.gbif.org/v1/species?datasetKey=73605f3a-af85-4ade-bbc5-522bfb90d847&datasetKey=d7c60346-44b6-400d-ba27-8d3fbeffc8a5' > | jq .results\[].datasetKey | wc -l > > >> 10 > > >> > > >> curl ' > https://api.gbif.org/v1/species?datasetKey=73605f3a-af85-4ade-bbc5-522bfb90d847' > | jq .results\[].datasetKey | wc -l > > >> 10 > > >> > > >> curl ' > https://api.gbif.org/v1/species?datasetKey=d7c60346-44b6-400d-ba27-8d3fbeffc8a5' > | jq .results\[].datasetKey | wc -l > > >> 7 > > >> > > >> We'd expect the first curl request to return 17 results given the > results of the datasetKey's individually. Not sure what is going on there. > This route does appear to accept multiple instances of the same parameter, > but not sure why the top curl call there doesn't return 17 results? > > >> > > >> Best, Scott > > >> _______________________________________________ > > >> API-users mailing list > > >> API-users at lists.gbif.org > > >> https://lists.gbif.org/mailman/listinfo/api-users > > > > > > _______________________________________________ > > > API-users mailing list > > > API-users at lists.gbif.org > > > https://lists.gbif.org/mailman/listinfo/api-users > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://lists.gbif.org/pipermail/api-users/attachments/20180209/d729abb5/attachment-0001.html>
