Back at the dawn of the web, the URL was created as a way of identifying and locating resources. A key characteristic of URLs on the web was the notion of a hierarchy, or tree, of resources defined by the path of the URL.
So many of the things that I need to do right now involve taking API design and slicing it into small pieces that can be easily communicated and acted upon. We are working to update our Microsoft Graph API design guidelines and publish them. We are working implementing our SDK generator (Kiota) and we need samples for testing. In the OpenAPI Initiative, we are always looking for more examples of how to use OpenAPI to describe APIs. But where do you start. There is so much to cover and breaking it down into pieces seems like a good first step.
It is true three women can't make a baby in 3 months, but it also doesn't take 27 months for them to have 3 babies!
Over the past few years, I have occasionally dreamed about what would be my perfect job. Of course it would have to involve HTTP APIs. But beyond that, my background in ERP software leaves me longing for solving business problems for users. My experience at Runscope as a developer advocate reaffirmed my desire to spend time helping other developers. Working with the OpenAPI Initiative over the past couple of years has allowed me to dip my toes into standards work that I have been fascinated with for so long. It’s a curious mix.
Although I know my HTTP and Web API pretty well, becoming an API Evangelist on the Azure API Management team means also needing to know the nitty gritty of the Azure API Management product too. In my learning process I have discovered a wealth of useful information, but it is scattered around a little. Some is on the Azure documentation site, some on Channel 9, some on YouTube and some awesome content from our Microsoft MVPs. This post is my attempt to gather it together to make it a bit easier to find.
In my last post I discussed what I perceive to be a misuse of the term self-description. I made the claim that one of the negative side-effects of this misuse is the development of more API metadata description languages. I believe this is a path we have travelled before and it is a dead end.
In my experience, once a SOAP API gets into production and is working, nobody wants to touch it. They can be very finicky beasts. Sometimes the most innocuous update can stop a client application in its tracks. Exposing a SOAP API to external customers just raises the risk level. One approach I frequently see is putting an HTTP or REST API in front of the SOAP stack. This adds a layer of indirection that allows some wiggle room into the exposed API. This blog posts talks about some of the issues to consider when trying to build a resource oriented HTTP API as a façade to a SOAP API.
After an interesting summer of working on OSS projects, doing a keynote in Australia at DDDMelbourne, and getting ever closer to finishing that Pluralsight course, I now have a new role to sink my teeth into