Resources definition convention over configuration

Topics: Web Api
Nov 1, 2010 at 5:00 PM

The attributes in the Contact Resource sample are not really telling anything else that cannot be inferred from the method definition:

 [WebGet(UriTemplate = "{id}")] public Contact Get(string id, HttpResponseMessage response)

[WebInvoke(UriTemplate = "{id}", Method = "PUT")]        public Contact Put(string id, Contact contact, HttpResponseMessage response)  

        [WebInvoke(UriTemplate = "{id}", Method = "DELETE")]        public Contact Delete(string id)

Would it be possible to make these attributes optional?

Or even get rid of them? Resources can only expose a single "operation" per HTTP method and I think it's reasonable to add the constraint that .NET method must match the HTTP verb. Regarding the UriTemplate, IHMO the best place to configure that is in the route definition and registration area anyway.

Finally the ServiceContract attribute on the class leaks WCF/SOAP settings such as the Namespace or ProtectionLevel. The suffix Resource and a certain namespace could be enough to identify resources... Or a new attribute specific to REST services where for example the OPTIONS functionality could be enabled/disabled declaratively

Nov 1, 2010 at 7:48 PM

Ok, I've just watched Glenn's PDC talk and I've seen that this is under the radar :)

Coordinator
Nov 4, 2010 at 8:14 AM

You mean ON the radar. We want to do it. We're actually discussing some design changes now that would make it much easier to introduce conventions.

Coordinator
Nov 4, 2010 at 5:37 PM

Javic

"The attributes in the Contact Resource sample are not really telling anything else that cannot be inferred from the method definition"

The id in the UriTemplate cannot really be inferred without making a bunch of assumptions. Uris can have other paramters as well. Just looking at the URI won't give you info of how to map.

Glenn

Nov 4, 2010 at 7:35 PM

Glenn,

With that statement I was refering to the HTTP methods, sorry that was really misleading!

Like I said, "Regarding the UriTemplate, IHMO the best place to configure that is in the route definition and registration area anyway." 

I agree that you would need a UriTemplate or some kind of convention definition to map URI's containing  for example dates or geolocation data... and I'd add those conventions right where the resource routes are configured.

Coordinator
Nov 4, 2010 at 7:45 PM

On Http method absolutely. I actually have a prototype that illustrates that exactly.

On UriTemplate there are two ways we are thinking to address this. If you are hosting in ASP.NET, you will be able to use routes. One interesting thing to think about is a single route mapping to multiple types depending on parameter values.

The second approach will support self-host / IIS scenarios. In that case we are looking into a configuration object which will allow you specify things like uri templates in a central piece of code rather than within the service.

Glenn