You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I like the addition of the key signup page right on the API doco, rather than pointing over to the api.data.gov. (Might be useful to mention here that they can re-use their API.DATA.GOV key.)
Good choice of typical API standards: UTF-8, JSON (also CSV available), ISO 8601/UTC dates.
Nice job including pagination.
Stuff To Think About
I'm not sure that having data on the end of the URL is necessary. It seems superfluous.
I would probably take agencies/<agency name> out of the URL path and pass it through the query string, i.e, /reports?agency_name=interior&api_key=DEMO_KEY1. The reason I suggest that is that the API is not really about agencies themselves (which is reflected in the fact that there is not an agencies endpoint). So it seems like the agency is really a query filter. However if future plans are to have a /agencies endpoint it would make sense to keep it there.
The API is returning an array, rather than a JSON object containing an array. This is one that contradicts the GSA API Standards, which is not the end of the world. But I also think the value of returning a JSON object is that it gives a useful wrapper for metadata about the result. A good usage in your case would be returning information about pagination, since you include that option.
Stuff to add in the future
This is a great start, so I know you'll keep improving it.
Add an endpoint for /reports/{id} using the report ID, e.g. /v1/reports/60716
After you add that endpoint, add a hypermedia link as an attribute of each report object, e.g,
Great job, very interesting API.
Some general feedback on this API:
Stuff I like
I like the addition of the key signup page right on the API doco, rather than pointing over to the api.data.gov. (Might be useful to mention here that they can re-use their API.DATA.GOV key.)
Good choice of typical API standards: UTF-8, JSON (also CSV available), ISO 8601/UTC dates.
Nice job including pagination.
Stuff To Think About
I'm not sure that having
data
on the end of the URL is necessary. It seems superfluous.I would probably take
agencies/<agency name>
out of the URL path and pass it through the query string, i.e,/reports?agency_name=interior&api_key=DEMO_KEY1
. The reason I suggest that is that the API is not really about agencies themselves (which is reflected in the fact that there is not anagencies
endpoint). So it seems like the agency is really a query filter. However if future plans are to have a /agencies endpoint it would make sense to keep it there.The API is returning an array, rather than a JSON object containing an array. This is one that contradicts the GSA API Standards, which is not the end of the world. But I also think the value of returning a JSON object is that it gives a useful wrapper for metadata about the result. A good usage in your case would be returning information about pagination, since you include that option.
Stuff to add in the future
This is a great start, so I know you'll keep improving it.
Add an endpoint for /reports/{id} using the report ID, e.g.
/v1/reports/60716
After you add that endpoint, add a hypermedia link as an attribute of each report object, e.g,
{ "id": 60716, "report_name": "today", "report_agency": "justice", "date_time": "2017-04-07T14:00:00.000Z", "link": https://api.gsa.gov/analytics/dap/v1/reports/60716, "data": { "visits": "4240" }, "created_at": "2017-04-07T04:23:55.792Z", "updated_at": "2017-04-07T04:23:55.792Z" }
The text was updated successfully, but these errors were encountered: