WebApiContrib

The  announcement of the ASP.NET Web API got a lot of people interested in playing with, bending, learning the framework to see what was possible to do with it. Some folks were doing that already back when it was WCFWebApi. But the move to the ASP.NET team and having it being part of the ASP.NET MVC 4 beta definitely brought a lot of attention to the Web Api framework.

The WebApiContrib organization

With all that attention, and people playing with it, different contrib efforts were sparkling all around. There was the original WcfWebApiContrib maintained by Darrel Miller. We at Headspring created our own contrib. Folks from Thinktecture created there own. Some other authors were pushing their own extensions to their own repositories. Basically, it was a mess.

Ryan Riley then started the effort to bring everybody together to contribute to a single contrib project. He created an organization on github and a mailing list. After I got contacted by Ryan, I talked with the other Headspring folks and we decided to transfer our WebApiContrib repository from our HeadspringLabs organization to the WebApiContrib one.

This was the first move that we made, after that, Thinktecture extensions were moved and the handlers from the WcfWebApiContrib were also moved.

How can I get it?

Right now, you can head to the github repository and pull the code. I know it’s kinda ghetto in these Nuget and Open Rasta OpenWrap days.

In order to fix this, and Chris Missal is working on it, we need to solve some few issues:

• Add the packaging task to our build – not a big deal
• Have a CI server to generate the packages for us – Chris talked with the Codebetter folks and we will have it done by the end of the week approximately
• Agree on how we are going organize the packages and distribute it.

The latter issue has two parts: package organization and distribution

Package Organization: We are structuring the code so that one can install the core package that has no dependencies. This will give you all extensions that have no extra dependencies. For extensions that depends on other packages we are going to create a specific packages.

For example, if you want to use the NotAcceptableMessageHandler, that has no dependencies, all you have to do is install the core package. On the other hand, if you want to use the ServiceStackTextFormatter, a Media Type Formatter that uses ServiceStack.Text to handle JSON serialization, you will have to install the WebApiContrib.Formatting.ServiceStackTextFormatter package. Our goal is to keep contrib’s users packages dependencies clean, and only have what is really necessary for what the user is trying to do.

Distribution: Nuget currently has two WebApiContrib packages. Those were created for the WCFWeb APIContrib project. This means that replacing those packages will break everything for people that was relying on the WCF version of the package. This might be ok to do, as the WCFWebApi no longer exist and we are going to deprecate the WCFContrib as well. But we haven’t decided that yet. And I’m willing to get some ideas on what should we do to make this as frictionless as possible.

I expect all this to be fixed by next week.

What’s next

We don’t have an official roadmap besides the issues list on github. Besides what’s there, I have some ideas that are now floating on my head but I haven’t started working on them yet:

Provide a better way of creating/embedding links on resources. The ASP.NET Web API has no built in helper to embed links into resources. My goal is to have a helper to make it easier, and hopefully in a strongly typed way, to configure your resource so that the Media Type Formatter can then pull that information and include the links in the resource representation.

Api Documentation Generation. It’s key for the success of a api that it’s well documented. It’s in the ASP.NET Web API team future roadmap to include something to help in this documentation generation. But, until they get there, we still need to document the web apis that we are creating. My initial idea is to implement the Swagger specification and use Swagger-UI to expose the documentation.

Remember it’s a Contrib effort

The goal of a Contrib effort is to group and curate extensions to the ASP.NET Web API that are created by the people using it. So, if you have an idea or created something that extends the ASP.NET Web API please, come talk to us. Send us an email on the mailing list; open an issue to discuss a new idea; send us a pull request. Even if you don’t have an specific idea or feature that you want to discuss but are willing to help our effort, come talk to us.  The WebApiContrib is a community effort and we need your help.