Posted on 06-30-2014
I’m working the great feedback we've had on APIs.json, an adding everything to the Github issues for consideration in the next version. Today I’m spending a little time thinking through the big picture of APIs.json, and some of the building blocks I'd like to see reflected when API providers generate their APIs.json.
Each API listed in an APIs.json has what we are calling: "Properties Elements”. The properties element is a collection, with two values: type and url. While we provide you with a base set of property element types you can reference:
Our goal is to continue providing, “reserved” types that we recognize, while also leaving properties elements, being as organic as possible—meaning you can define your own references, and tell the story of why these are important building blocks in your own API strategy. We will continue adding the best properties we see being used, to the APIs.json spec.
To prepare for the next version of APIs.json, I want to have the next list of reserved property types. Working from my list of API management building blocks I’ve identified X I’d like to see in the next version:
These are the building blocks I think are important to API operations. Currently all of these will be links to human readable pages, within an APIs developer portal, but eventually I envision all of these potentially being machine readable.
I know, this is a big vision, but I intend to make it a reality. The first machine readable element on this list is the InterfaceLicense, which will reference the machine readable JSON manifest for API Commons.
Next on the list is TermsOfService, which I will be using Terms of Service Didn’t Read’s machine readable format, and applying it to the world of APIs. If there are any types you’d like to see in the next version of APIs.json, head over to the Github issue I created for this discussion, and make sure it is on the list.
comments powered by Disqus
Winning in the API Economy
|Download as PDF|
Latest Blog Posts
- My API 101 Workshop At @APIStrat In Chicago Next Week
- Some Advice For The Enterprise When Beginning Your API Journey
- Machine Readable API Definition Format Swagger Matures to 2.0
- How Do We Continue Moving Green Button Data And APIs Forward?
- Beyond Public APIs In Government: Internal Access to Resources
- Can You Show Me The ROI On All Of This API Stuff Before We Commit
- In The Future APIs Will Be Default For All Cities
- No Public APIs Are Not Going Away Just Cause A Few BigCos Fumble At It
- Internal API Search Engine For Everyone At Your Company (Not Just Developers)
- If You Need Assistance With Your Healthcare API Strategy I Have The Person
- Explaining APIs To Senior Leadership: Access To Company Resources Without The IT Hassle
- A Conversation With @ijroth, @dorkitude, @antonyfalco, and @medjawii In The Next Generation API Stack Panel @APIStrat
- API Evangelist Thoughts On The Right To An API Key And Algorithmic Organizing
- Explaining APIs To Your Senior Leadership
- An API Evangelism Strategy To Map The Global Family Tree
- Thank You For Your API Evangelist Blog(s)
- Video From The Hypermedia Panel At API-Craft In Detroit Last Month
- Please Open Source Your API Before Shutting It Down
- Explaining My Work Around APIs In Higher Education To Institutions
- You Can Have An API Just By Choosing Products And Services That Have APIs
- Using Excel As An API Datasource And An API Client For The Masses
- Brewing Up Something Awesome With The Jive Software API
- Relationship Between APIs And Containers
- Real-time and Visualizations Will Be Key in Financial API Deployments
- Notification Focused Startups Within Leading API Ecosystems