POST tunneling in ADO.NET Data Services

Today's topic is about the UsePostTunneling property on the DataServiceContext type.

The ADO.NET Data Services Framework was designed around RESTful principles, so it maps operations on entities to HTTP methods. So for example:

  • To read an entity, we make a GET request to the URI that refers to that resource.
  • When we create a new entity in an entity set, we POST a representation of the entity to the URI for the entity set.
  • We use DELETE to delete an entity, using its URI.
  • PUT or MERGE are used to update an entity. The difference betwen them is that MERGE requests that the server doesn't overwrite properties that aren't specified in the representation.

Unfortunately, not every implementation of the HTTP network stack is happy with these methods. Sometimes only partial support is available; other times an intermediate party like a firewall may choose to deliberatly block requests with certain methods. Bottom line is, GET and POST typically work everywhere, and all other methods have the possibility of running into trouble, sometimes in ways or places that you might not be able to control.

If you happen to be in an environment where methods other than GET and POST are a problem, you can set the UsePostTunneling property to true. When you do this, POST will be used and the real method will go in a custom header. This is generally considered less RESTful because now the request method won't necessarily match the request intent, but it does have the valuable trait of allowing your application to work.