Compartir a través de

POST tunneling in ADO.NET Data Services

  • Artículo

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.

Comments

  • Anonymous
    August 21, 2008
    What is the custom header? A "_method" value? Thanks for the reminder about this feature. Though its documentation is rather scant. I'd love some samples of using this tunneling with jQuery and Data Services on the web. Blogs and documentation almost assume the only client apps using this would be Silverlight. But Data Services could be very useful for broader usage, in AJAX cases.

  • Anonymous
    August 22, 2008
    Andy, the custom header name is 'X-HTTP-Method'. Just set its value to whichever HTTP method you would have sent if you didn't have to use the workaround. IIRC, the server will reject tunneled requests for GET and POST, which should always be available, as a way to provide a further incentive to keep REST semantics aligned with HTTP requests.