-
Notifications
You must be signed in to change notification settings - Fork 80
Resources
- Hypertext Application Language
- The HAL Browser
- Collection+JSON Hypermedia Type
- Why HATEOAS
- From REST to HATEOAS
- The REST Cookbook
- The Link HTTP Header
-
These standards are proposed by the White House for their current and future APIs. We should adhere to them as much as possible in order to foster good will and ease of reuse between government entities.
-
OData is incredibly comprehensive and is a standard supported by Microsoft, IBM, and the Open Government Data Initiative (OGDI). However, it's incredibly complex, and the best tools for working with it are all .NET. Not sure supporting this is feasible/a good idea. Looking at the examples from Netflix will give you a good idea of how complex this can be.
-
Open Data Protocols/Simple Data Format
This couldn't have a more confusing name if it tried. Much simpler, much easier to implement set of proposed standards. Problem: lots and lots of open questions, not a lot of answers. Specifications are still being made. This is good, as it allows us flexibility; it's not so great, in that it means we are pretty much making it up. The metadata format should be expanded to work more like DSPL.
-
Dataset Publishing Language (DSPL)
Google's standard for creating datasets to import into the Google Public Data Explorer. I love this one, although it's pretty complex. The metadata that you give it will allow us to automatically generate API parameters. This doesn't include a standard for the API, just for the dataset.
-
Socrata's Open Data API isn't a bad place to start for designing our API. In particular, the SODA2 SoQL query language looks easy to implement and yet is full-featured.
-
Swagger is a specification for programatically describing an API, allowing it to be discoverable, as well as a set of tools for documenting and consuming Swagger-compatible APIs.