/dataset/<id>/metrics route gives 204 for some dataset IDs
17740
Reporter: scott
Type: Bug
Summary: /dataset/<id>/metrics route gives 204 for some dataset IDs
Priority: Minor
Status: Open
Created: 2015-07-31 21:39:07.201
Updated: 2017-08-10 18:03:31.685
Description: Some API calls gives a 204 response. 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 the 204 means that that dataset ID is not found? Or is it meant to indicate something else? I would have expected a 404 response. There's no other info in the headers to indicate the issue (I realize a 204 should not return a body). This dataset doesn't have metrics data http://www.gbif.org/dataset/3f8a1297-3259-4700-91fc-acc4170b27ce/stats
Or, maybe the idea here is that 404 is not appropriate since the dataset ID exists, but has no metrics data?
Another issue: Docs say this route will work for datasets of type CHECKLIST only http://www.gbif.org/developer/registry#datasetMetrics - E.g., curl on this dataset that is not of type CHECKLIST (it's an OCCURRENCE type) http://api.gbif.org/v1/dataset/d4b72404-5c42-49ea-ab78-9edb3c8957b6/metrics gives the same result as the above type CHECKLIST dataset. I wonder if these should give different errors?]]>
Author: trobertson@gbif.org
Created: 2016-09-01 21:59:16.33
Updated: 2016-09-01 21:59:16.33
Can you please confirm this is still an issue?
I believe it now behaves as documented (204 for the occurrence) and the checklist works. This leads me to think it was perhaps an outage on our end - possibly during a redeploy. Is it something that can reproduced on your end please?
Author: scott
Created: 2016-09-01 22:27:27.676
Updated: 2016-09-01 22:27:27.676
This request works now (gives 200)
curl -v 'http://api.gbif.org/v1/dataset/3f8a1297-3259-4700-91fc-acc4170b27ce/metrics'
But this request still gives a 204 error
curl -v 'http://api.gbif.org/v1/dataset/d4b72404-5c42-49ea-ab78-9edb3c8957b6/metrics'
* Trying 130.226.238.135...
* Connected to api.gbif.org (127.0.0.1) port 80 (#0)
> GET /v1/dataset/d4b72404-5c42-49ea-ab78-9edb3c8957b6/metrics HTTP/1.1
> Host: api.gbif.org
> User-Agent: curl/7.43.0
> Accept: */*
>
< HTTP/1.1 204 No Content
< Content-Type: application/json
< Access-Control-Allow-Origin: *
< Access-Control-Allow-Methods: HEAD, GET, POST, DELETE, PUT
< Server: Jetty(9.3.z-SNAPSHOT)
< x-api-url: /v1/dataset/d4b72404-5c42-49ea-ab78-9edb3c8957b6/metrics
< Accept-Ranges: bytes
< Date: Thu, 01 Sep 2016 20:27:15 GMT
< X-Varnish: 2144146017
< Age: 0
< Via: 1.1 varnish
< Connection: keep-alive
<
* Connection #0 to host api.gbif.org left intact
Author: scott
Created: 2017-08-09 19:20:15.113
Updated: 2017-08-09 19:20:15.113
This is coming up again - reported by an rgbif user https://github.com/ropensci/rgbif/issues/270
Seems this is still an issue - not saying it's wrong - i just don't know what behavior you want the API to have. Maybe replacing the 204 code with 404 - or if stick with 204 code, at least some kind of header message or body error message about why the server is not returning any content
Author: trobertson@gbif.org
Created: 2017-08-10 17:58:29.206
Updated: 2017-08-10 17:59:04.936
Thanks - agree it could be made more intuitive, but is by some design - 204 indicating that there is no content for this, but implying that one day there may well be.
Author: scott
Comment: Thanks. Makes sense now. I'll probably add an additional message when we get a 204 on this route telling users that metrics are only avail. on checklists
Created: 2017-08-10 18:03:31.685
Updated: 2017-08-10 18:03:31.685