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
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@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@lists.gbif.org http://lists.gbif.org/mailman/listinfo/api-users
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@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@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@lists.gbif.org http://lists.gbif.org/mailman/listinfo/api-users
participants (2)
-
Scott Chamberlain -
Tim Robertson