Yesterday, I had a thought. It didn't fit into a tweet so wrote a few paragraphs. I was very pleased with myself, finally getting round to writing again after a few months off. That was, until two different people who I respect highly, told me I was wrong. That part sucked.
Here's a thought that wouldn't fit into a tweet and will serve the purpose of breaking my blogging dry spell. With all the attention that microservices is currently receiving I regularly hear people talking about service discovery. When trying to co-ordinate multiple different services working together, it is critical to be able to dynamically configure which services will perform what services, for which consumers.
I recently needed to create a new Web API project for some content I'm working on for a talk. I decided I might as well use the ASP.NET Web API Template to get started.
If you spend any time reading about API design or working with APIs you will likely have come across the notion of paging response data. Paging has been used in the HTML web for many years as a method to provide users with a fast response to their searches. I normally spend my time advocating that Web APIs should emulate the HTML web more, but in this case I believe there are better ways than slicing results into arbitrary pages of data.
Part of my role at Runscope involves me writing OSS libraries or sample projects to share with other developers. I also regularly use 3rd party APIs in the process. This requires the use of API keys and other private data that I'd rather not share. Unfortunately it is all too easy to leave a key in a source code file and accidentally commit it to a public source control repository.
When writing the Web API book, we decided that there was no way we would ever finish if we tried to address every conceivable issue. So we decided to setup a Google Group where readers of the book could ask for clarifications and ask related questions. One question I received a while ago has been sitting on my to-do list for way too long. The question from Reid Peryam is about query resources. This is my answer.
Fast iterations can be very valuable to the software development process, but make for more time spent doing deployments and testing. Also, more deployments means more opportunities to accidentally introduce breaking changes into your API.
If you are building an ASP.NET Web API and want a view into the HTTP traffic that is hitting your API then this is a really quick solution that might prove useful.
Uber recently announced the availability of a public API. I decided to take it for a spin and provide some commentary. The quick version is that it is a fairly standard HTTP API and that is both a good thing and a bad thing.
ASP.NET Web API 2.1 introduced some significant improvements to the mechanisms that support global error handling. Before this release there were a number of different types of errors that would be handled directly by the runtime and there was no easy way to intercept these errors and add your own custom behavior. The standard guidance suggests you register these new handlers as services, but I prefer a different approach that seems more natural to me.