One of the principles of REST is to use “Hypermedia As The Engine Of Application State” (HATEOAS). This means that a web service should provide its clients with all the information they need in order to interact with the service… and this information should be provided along with the response to any request. Most people understand this to mean URIs should be embedded into the responses that are served, so that a client can follow the links in order to change the application state. However, something else that the HTTP standard provides in order to support this discoverability is the Allow header that the server can populate to indicate which HTTP methods a resource support. The Resources Over MVC (ROM) assembly allows this header to be supported.

More...

The Resources Over MVC (ROM) assembly allows your RESTful web service to serve multiple representations. Out of the box it supports JSON and XML. One advantage of creating a web service using ASP.Net MVC rather than Windows Communication Foundation (WCF) is that you also get great support for serving XHTML as another representation. This allows a developer to investigate your web service with their browser. In this post we’ll look at providing help (and a test harness) for the client developer directly within the web service.

More...

Simple Clients Part 1 explained how introducing the MapRomRoute extension methods from the the Resources Over MVC (ROM) assembly allows simple User Agents to request resources in a particular format using a query string parameter. This post looks at how the same extension also allows User Agents to “Overload” the POST method if they don’t support the full range of HTTP Methods.

More...

In an earlier post we created a Bare Minimum web service that supported XHTML, JSON and XML, but it did not make it easy for us to request one of the alternate representations directly from a web browser (as opposed to using JavaScript) as the user can’t change the Accept type the browser sends. It’s not only web browsers that can have this problem. There are many User Agent SDKs out there that don’t allow the developer to set the Accept header. This post shows how the sample introduced in the A More Complex Sample post uses the Resources Over MVC (ROM) assembly to create a RESTful web service (developed using ASP.Net MVC) to allow less sophisticated User Agents to specify the format they want. As ever… its just one line of code!

More...

The previous Bare Minimum posts showed how to use the Resources Over MVC (ROM) assembly to add some RESTful features to a web site developed using ASP.Net MVC. This post introduces a second sample project that will be used in future posts to demonstrates the other functionality available within ROM.

More...

Bare Minimum Part 1 of this series showed how to add a read only web service to an ASP.Net MVC web site with one line of code. In this post we’ll add a second line of code to give us a web service that can receive data.

More...

This series of posts is introducing the features in the ROM code. If you haven’t been there already, take a look at the introduction and perhaps download the source from CodePlex. The absolute minimum you need to get going with Resources Over MVC (ROM) is an existing ASP.Net MVC web site, a reference to the ROM assembly (via NuGet) and a single line of code.

More...

Over the last couple of years I have been blogging about using writing a RESTful web service using ASP.Net MVC. I’ve decided to put this code onto CodePlex and publish it via NuGet. Over the next few days I’ll publish a number of posts in which I’ll take you through creating a basic web service using the Resources Over MVC (ROM) assembly.

More...

Recently MVC 3 was released which is a good reason for me to update our RESTful web service framework. This latest version is compiled against ASP.Net MVC 3 and .Net 4. I have also taken the opportunity to introduce some new features that have either been requested or come out of actual implementations.

More...

Joel Feaster emailed to say he was having trouble with the Accept header handling of the web service. When he used jQuery’s getJSON method it would use the following Accept header:

application/json, text/javascript, */*

You’ll notice there are no q parameters in that header, so according to the HTTP 1.1 specification, they should all be treated as having a q value of 1. However, the specification does not dictate which format should take precedence when all acceptable formats have the same q value. But looking at that header and knowing it comes from a method named getJSON, you might hope the web service would pick application/json.

More...