Hi Tim, Yes, opened an issue. http://dev.gbif.org/issues/browse/POR-2809
-Scott On Fri, Jul 31, 2015 at 11:52 AM Tim Robertson <trobertson at gbif.org> wrote: > 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/1a5de2cb/attachment.html>
