Using [WebGet(UriTemplate=....)]

Topics: Web Api
Jan 17, 2011 at 10:54 AM

This is probably my lack of knowledge but why do I need to specify a WebGetAttribute for something like this:

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

Shouldn't that be the default?

Cheers
John

Coordinator
Jan 17, 2011 at 11:13 AM

This assumes that the uri has a single uri segment. i.e. contact/5. However we can't always assume that. For example there could be multiple segments like /contact/5/foo. Or there could be zero additional segments in the case of a collection resource like /contacts.

I did do explore in a spike I did on the resource model of introducing a convention where if a resource is an "item" resource then plug in the id by default. I am not sure if that makes sense as something we bake in, but it is worth considering.

Jan 17, 2011 at 10:54 PM

I get that, but what I'm trying to say is that [WebGet(UriTemplate = "{id}")] should be optional.

So if the user want to expose a uri as contact/5 then I shouldn't need the attribute, that uri style should be the default.
But if I want something different eg /contact/5/foo then I need to add the attribute [WebGet(UriTemplate = "{id}/foo")]

And in the case of a collection resource that should be inferred too, because of the method signature without any parameters:

[WebGet(UriTemplate = "")]  <-- Shouldn't need this!
public List<Contact> Get()

 

Does that make sense?

Coordinator
Jan 17, 2011 at 11:20 PM

You are asking about the attributes in general. As I mentioned in my resource model blog post, we are looking at introducing a convention based model that would not require that information via attributes. [WebGet] is the existing mechanism for doing that which is explicit.

Glenn

Jan 18, 2011 at 1:30 AM

John,

IMHO, you are absolutely right about the fact that the WebGet attribute could be inferred.  However, my perspective is that the whole WebHttp project that is under the prototype folder serves just two purposes.  It proves that the new HTTP Stack is flexible enough to simulate the old System.ServiceModel.Web methodology and it provides a transition path for existing System.ServiceModel.Web users to the new HTTP stack.  

I think that System.ServiceModel.Web got a bunch of things wrong about the way it exposes REST resources and representations, but instead of trying to fix the WebHttp clone of System.ServiceModel.Web, and potentially breaking backward compatibility, we should be focusing on building out a new model that is done a better way.

 

Just my opinion though,

Darrel

Coordinator
Jan 18, 2011 at 1:55 AM

Yes, although what we are doing now I believe is a dramatic improvement over the current WCF HTTP model, we are not stopping there. We are looking at providing a model much more suitable for resources. That model is TBD at this point. Even the blog post I mentioned basically just shows removing attributes. We're oging to go much further than that. It's very likely we will introduce a new concept to WCF....Resource :-)

Jan 18, 2011 at 2:00 AM
gblock wrote:

Yes, although what we are doing now I believe is a dramatic improvement over the current WCF HTTP model, we are not stopping there. We are looking at providing a model much more suitable for resources. That model is TBD at this point. Even the blog post I mentioned basically just shows removing attributes. We're oging to go much further than that. It's very likely we will introduce a new concept to WCF....Resource :-)

That's good because when I'm writing here I never know if I should use "Resource" or "Service" or even "Contract implementation", which one is it?