Recent Posts

  • A drive by review of the Uber API

    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. Continue reading...

  • Centralized exception handling using a ASP.NET Web API MessageHandler

    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. Continue reading...

  • These 8 lines of code can make debugging your ASP.Net Web API a little bit easier.

    I think most us ASP.Net Web API developers have, at some point, experienced the problem where their API is returning a 500 Internal Server Error, but tracing through with Visual Studio doesn't reveal any exceptions in our code.  This problem is often caused when a MediaTypeFormatter is unable to serialize an object.  This simple message handler can take away some of the pain of debugging these scenarios. Continue reading...

  • Everything you need to know about HTTP Header syntax but were afraid to ask

    If you use HTTP then the chances are good that you have to deal with HTTP headers.  The syntax of HTTP headers has a long and tortured history, originating from the syntax of email headers.  All too often I see headers that don't conform to the specifications.  This makes everyone's job a little bit harder.  The recent releases of the HTTP specifications have done a fair amount of clarification and consolidation to make getting the syntax right. Continue reading...

  • Hypermedia as the engine of application state, the client-server dance

    We are currently seeing a significant amount of discussion about building hypermedia APIs.  However, the server side only plays part of the role in a hypermedia driven system.  To take full advantage of the benefits of hypermedia, the client must allow the server to take the lead and drive the state of the client.  As I like to say, it takes two to Tango. Continue reading...

  • The Insanity of the Vary Header

    In my first deep dive into a HTTP header on the user-agent header I said that I would try and produce a series of posts going under the covers on certain HTTP headers.  This post is about the Vary header.  The Vary header both wonderful and sad at the same time.  I'll discuss how to make it work for you and where it fails miserably. Continue reading...

  • Composing API responses for maximum reuse with ASP.NET Web API

    In Web API 2.1 a new mechanism was introduced for returning HTTP messages that appeared to be a cross between HttpResponseMessage and the ActionResult mechanism from ASP.NET MVC.  At first I wasn't a fan of it at all.  It appeared to add little new value and just provide yet another alternative that would a be a source of confusion.  It wasn't until I saw an example produced by Brad Wilson that I was convinced that it had value. Continue reading...

  • An HTTP Resource is a lot simpler than you might think

    Unfortunately, I still regularly run into articles on the web that misunderstand the concept of an HTTP resource.  Considering it is a core piece of web architecture, having a clear understanding of what it means can make many other pieces of web architectural guidance considerably easier to understand. Continue reading...

  • Single purpose media types and reusability

    The one great thing about twitter is that you quickly find out what you failed to explain clearly :-)  My efforts in advocating for single purpose media types failed to clarify that by single purpose, I am not suggesting that these media types should not be re-usable.  Let me try and explain. Continue reading...

  • Single purpose media types and caching

    My recent post asking people to refrain from creating more generic hypermedia types sparked some good conversation on twitter between @mamund, @cometaj2, @mogsie, @inadarei and others.  Whilst thinking some more on the potential benefits of single purpose media types versus generic hypermedia types, realized there is a correlation between single purpose media types and representation lifetimes.  I thought it might be worth adding to the conversation, but there is no way I could fit it in 140 chars, so I’m posting it here. Continue reading...

  • XSLT is easy, even for transforming JSON!

    Most developers I talk to will cringe if they hear the acronym XSLT.  I suspect that reaction is derived from some past experience where they have seen some horrendously complex XML/XSLT combination.  There is certainly lots of that around. However, for certain types of document transformations, XSLT can be a very handy tool and with the right approach, and as long as you avoid edge cases, it can be fairly easy. Continue reading...

  • Please, no more generic hypermedia types

    This opinion has been stewing for a couple of years now, but following an excellent conversation I had with Ted Young the other evening at the API Craft San Francisco event, I think it is time to have more discussion around this subject. Continue reading...

  • Self-descriptive, isn't. Don't assume anything.

    With the recent surge of interest in hypermedia APIs I am beginning to see the term “self-descriptive” thrown around quite frequently.  Unfortunately, the meaning of self-descriptive is not exactly self-descriptive, leading to misuse of the term.  Continue reading...

  • Distributed Web API discovery

    The site apisjson.org defines a specification for creating a document that declares the existence of an API on the web.   This document provides some identification information about the API and links to documentation and to the actual API root URL.  It also supports pointing to other resources like API design metadata documents and contact information for maintainers of the API. Continue reading...

  • Returning raw JSON content from ASP.NET Web API

    In a previous post I talked about how to send raw JSON to a web API and consume it easily.  This is a non-obvious process because ASP.NET Web API is optimized for sending and receiving arbitrary CLR object that then get serialized by the formatters in the request/response pipeline.  However, sometimes you just want to have more direct control over the format that is returned in your response.  This post talks about some ways you can regain that control. Continue reading...

  • There is Unicode in your URL!

    In our Runscope HipChat room a few weeks ago, I was asked about Unicode encoding in URLs.  After a quick sob about why I never get asked the easy questions, I decided it was time to do some investigating.  Continue reading...

  • Sharing Fiddler requests using Runscope

    Fiddler is an excellent tool that I have been using for many years to debug HTTP requests in local applications.  However, one of the things that Fiddler can't do easily, out of the box, is allow you to share requests with other team members.  Sometimes it is nice to be able to show someone a HTTP request/response for debugging or design related issues. I recently a built an extension to Fiddler that takes advantage of Runscope's request sharing mechanism, to make sharing a request captured by Fiddler a one click affair. Continue reading...

comments powered by Disqus