Designing the Octopus Deploy 2.0 HTTP API
For the next release of Octopus Deploy we're going to be moving to an API-first model. To support this, much of the Octopus web portal is going to be rebuilt.
While I originally planned to do this using the two headed monster that is ASP.NET and WebAPI, this week I've been experimenting with using Nancy to serve both the web API and web pages, and I have to say, I'm impressed.
One of the most attractive features of Nancy is portability; it can run self-hosted inside our Octopus windows service, or on is own in IIS under ASP.NET for customers who for some reason really want to stick with IIS. The self hosting option is great because it means that, out of the box:
- We don't need to worry so much about whether ASP.NET is registered with IIS, or whether the right IIS features are installed and enabled
- We don't need to worry about the wierd changes customers may have made to their IIS configurations, like deleting all the default MIME type mappings
And since Nancy works well for both building API's and web sites, we don't have to duplicate our routing, linking and authentication code the way I did with ASP.NET MVC and WebAPI.
I'm also working hard on the API and documenting it from the start. You can see the beginnings of this in the API documentation repository on GitHub. The goals of the API are:
- To be friendly and easy to figure out
- To be hypermedia driven, using links and the occasional URI template (see an example)
- To support all of the features that the UI requires
- To have a nice client library for .NET available via NuGet
As I go, I'm also raising a few questions about the API design on the GitHub issues page; if you're interested in HTTP API designs I'd love for you to take a look!