I agree, that seems like incorrect behaviour Scott - I would expect 404 too. http://www.gbif.org/dataset/3f8a1297-3259-4700-91fc-acc4170b27ce/stats
Can you please file an issue? I am on my phone In haste, Tim On 31 Jul 2015, at 19:52, Scott Chamberlain <myrmecocystus at gmail.com> wrote: > Hi all, > > I am curious as to the reasoning behind the 204 response for some API > requests. For example: > > curl -v > 'http://api.gbif.org/v1/dataset/3f8a1297-3259-4700-91fc-acc4170b27ce/metrics' > > < HTTP/1.1 204 No Content > < Content-Type: application/json > < Access-Control-Allow-Origin: * > * Server Jetty(9.2.z-SNAPSHOT) is not blacklisted > < Server: Jetty(9.2.z-SNAPSHOT) > < x-api-url: /v1/dataset/3f8a1297-3259-4700-91fc-acc4170b27ce/metrics > < Accept-Ranges: bytes > < Date: Fri, 31 Jul 2015 17:46:32 GMT > < X-Varnish: 1108784184 > < Age: 0 > < Via: 1.1 varnish > < Connection: keep-alive > > I assume this means that that dataset ID is not found? If so, I would have > expected a 404 perhaps. There's no other info in the headers, so I'm not > sure what other reason there is for no data returned (I realize a 204 should > not return a body). I know this dataset ID used to return data, as I used it > in examples for hitting the /dataset/*/metrics route > > In other APIs I get a 204 on a successful DELETE request - that's the only > context I'm familiar with wrt 204's > > Thanks! Scott > _______________________________________________ > API-users mailing list > API-users at lists.gbif.org > http://lists.gbif.org/mailman/listinfo/api-users -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.gbif.org/pipermail/api-users/attachments/20150731/b551dc13/attachment.html>
