Cut of the extension mapping

Topics: Web Api
Dec 5, 2011 at 9:36 AM

Hi guys,

Is it a choice to not have the extension mapping snipped off automatically?

For example, this:

http://test.com/contact/80.json

(added using "AddUriPathExtensionMapping" in the formatter)

Will add an Accept type to the header but it won't snip off '.json'. So my webservice method will still receive "80.json" in it's argument. Which fails because it expects an Int32.

Any suggestions?

Thx,

Gerben.

Coordinator
Dec 5, 2011 at 2:14 PM
If you look at the ContactManager Advanced there is a message handler UriExtensionHandler that does just that.

Sent from my Windows Phone

From: GerbenRampaart
Sent: 12/5/2011 2:36 AM
To: Glenn Block
Subject: Cut of the extension mapping [wcf:281823]

From: GerbenRampaart

Hi guys,

Is it a choice to not have the extension mapping snipped off automatically?

For example, this:

http://test.com/contact/80.json

(added using "AddUriPathExtensionMapping" in the formatter)

Will add an Accept type to the header but it won't snip off '.json'. So my webservice method will still receive "80.json" in it's argument. Which fails because it expects an Int32.

Any suggestions?

Thx,

Gerben.

Coordinator
Dec 5, 2011 at 4:43 PM

Yes, this is a known issue – you currently have to account for the URI extension explicitly in your URI template.

There is some sample code in the advanced contact manager sample that shows how you can implement an alternative mechanism that uses the last URI segment to do the accept header mapping instead of using the .ext syntax.

Daniel Roth

Dec 5, 2011 at 5:47 PM
But if that uriextensionhandler actually adds the http accept header, what use does the AddUriExtensionMapping of the formatter have?

Sent from my iPhone

On 5 dec. 2011, at 18:43, danroth27 <notifications@codeplex.com> wrote:

From: danroth27

Yes, this is a known issue – you currently have to account for the URI extension explicitly in your URI template.

There is some sample code in the advanced contact manager sample that shows how you can implement an alternative mechanism that uses the last URI segment to do the accept header mapping instead of using the .ext syntax.

Daniel Roth

Coordinator
Dec 5, 2011 at 6:02 PM

You can still use the UriPathExtensionMapping if your URI template has the form “foo{ext}”. Where it doesn’t work is when the last segment in your URI path has variable content. You can do “{foo}.{ext}”, but then all of our requests will need to include the dot, even when a path extension is not being used.

Daniel Roth

Dec 5, 2011 at 6:11 PM
I understand. It seems though like this is a place where convention over configuration would work best imho. I really wouldn't mind if you guys would force me to always do this when I use extension mappings: resource/12.json

Firstly because this looks really nice: employee/123.png and secondly because it just seems odd that adding a querystring extension ("format", "json") works out of the box but uri extensions turn out way more tedious.

Sent from my iPhone

On 5 dec. 2011, at 20:02, danroth27 <notifications@codeplex.com> wrote:

From: danroth27

You can still use the UriPathExtensionMapping if your URI template has the form “foo{ext}”. Where it doesn’t work is when the last segment in your URI path has variable content. You can do “{foo}.{ext}”, but then all of our requests will need to include the dot, even when a path extension is not being used.

Daniel Roth

Coordinator
Dec 5, 2011 at 6:39 PM

"force me to always do this when I use extension mappings"

Uri extensions have nothing to do with HTTP or content negotation. The idea of server driven conneg is a client comes with a set of accept headers against a resource and the server can determine which representation best matches the clients preferences. The server can also return a Content-Location header indicating the uri of the negotiated resource or redirect to it directly. That location is a bookmark to the specific representation that was returned allowing the client to refer to it directly in the future. This prevents the client from having to know how to build up uris / locking the server down to a specific uri space.

For example

  • Client comes with an accept header of "image/png" to "contact/1".
  • Server does conneg and sees that "image/png" is supported.
  • Server returns client the image/png representation along with a Content-Location of "/contact/1.png".
  • Client saves the link as a bookmark. User copies the link into their paint program and opens the image directly

In all of this exchange the client did not have to learn about which extensions were supported in the uri space. The server fed the client the uris which the client held on to for future use.

If you force the extensions, that means the clients have to know the accepted extensions of the sever. That semantic is not at all part of HTTP, yet accept headers are.