processing REST requests in C#

[mmc]

Hi all,
I've been using C# for a long time, but am somewhat new to REST, and
have what I'm sure are real newbie questions:

I want to develop a RESTful Web Service API that will be able to
handle requests of the form

http://mydomain.com/widgets/france --(returns all widgets available
in france)
http://mydomain.com/widget/1234 -- (returns data about widget # 1234)
http://mydomain.com/widget/1234/costInDollars --(returns the price of
widget #1234 in $)
http://mydomain.com/widget?id=1235&name=NewWidget&costUS=25.5&country=Spain
--(creates a new widget with an id of 1235, a name of NewWidget, a
costInDollars of $25.50, and an available-in-country of Spain.

My questions:
1) are these "RESTful calls"? (I'm pretty sure the first 3 are, but
is the last one a reasonable syntax for "add widget"?
2) On the server side, does the HTTP handler simply parse the URL to
retrieve the object type, ID, etc. (and retrieve the QueryString
params normally), or is there a streamlined way to break about the
URL?

Thanks in advance for any help!

 

[Pavel Minaev]

I've been using C# for a long time, but am somewhat new to REST, and
have what I'm sure are real newbie questions:

I want to develop a RESTful Web Service API that will be able to
handle requests of the form

http://mydomain.com/widgets/france --(returns all widgets available
in france)
http://mydomain.com/widget/1234 -- (returns data about widget # 1234)
http://mydomain.com/widget/1234/costInDollars --(returns the price of
widget #1234 in $)
http://mydomain.com/widget?id=1235&name=NewWidget&costUS=25.5&country=Spain
--(creates a new widget with an id of 1235, a name of NewWidget, a
costInDollars of $25.50, and an available-in-country of Spain.

My questions:
1) are these "RESTful calls"? (I'm pretty sure the first 3 are, but
is the last one a reasonable syntax for "add widget"?

It's not. The URL you provided clearly indicates that it will be an HTTP GET
request. According to REST principles as applicable to HTTP, creating new
objects is represented by HTTP POST. So, HTTP GET for
http://mydomain.com/widgets/ returns the list of all widgets, and HTTP POST
to http://mydomain.com/widgets/ adds a new widget.

Also, you shouldn't vary singular/plural. So it's "widgets/1234", and not
"widget/1234" (this is to maintain the proper URL hierarchy - a specific
widget is a child of the entire collection of widgets).

2) On the server side, does the HTTP handler simply parse the URL to
retrieve the object type, ID, etc. (and retrieve the QueryString
params normally), or is there a streamlined way to break about the
URL?

To begin with, in .NET 3.5 SP1, there's ADO.NET Data Services, which
(almost) seamlessly provides RESTful services on top of anything that
implements IQueryable<T> and IUpdatable. If you're a conventional REST layer
on top of your data model, it may well be just what you need (and if your
data storage is MSSQL, then you can use Entity Framework to map it to EDM,
which Data Services can consume, and save even more time).

Otherwise, why not use ASP.NET? You'll have to ignore all the Web Forms
stuff, of course, but you'll get to use some handy classes such as
HttpRequest and its Form property, which will parse those name/value pairs
in GET/POST/PUT requests for you.

 

[mmc]

Thanks very much, Pavel. That's exactly the kind of feedback I was
hoping for.

Regarding the server-side stuff, I plan to use ASP.NET, and will
explore the .NET 3.5 ADO.NET Data Services stuff you describe.
Happily, we're also using SQL Server, so I'll also look into the
Entity Framework stuff.

I still don't think I'm 100% clear on how to decompose the
"mydomain.com/widgets/1234/costInDollars" type URL into its composite
parts (e.g the widget ID, etc.), but maybe there are HttpRequest
methods and/or other mechanisms to do that for me.

Thanks again!

 

[Pavel Minaev]

Thanks very much, Pavel. That's exactly the kind of feedback I was
hoping for.

Regarding the server-side stuff, I plan to use ASP.NET, and will
explore the .NET 3.5 ADO.NET Data Services stuff you describe.
Happily, we're also using SQL Server, so I'll also look into the
Entity Framework stuff.

I still don't think I'm 100% clear on how to decompose the
"mydomain.com/widgets/1234/costInDollars" type URL into its composite
parts (e.g the widget ID, etc.), but maybe there are HttpRequest
methods and/or other mechanisms to do that for me.

Yes, you can use the same class that Data Services uses - it's called
UriTemplate, introduced in 3.5 (plain one, pre-SP1). You can define a
template like this (MSDN example):

weather/{state}/{city}?forecast={day}

and then you use UriTemplate.Match to match this template against the URI,
and retrieve the matched values from the returned UriTemplateMatch object.

You can look at the complete example here:
http://msdn.microsoft.com/en-us/library/system.uritemplate.match.aspx

By the way, it seems that WCF in 3.5+ allows very seamless creation of
RESTful web services based on those URI templates. It would look like this:
[DataContract(Namespace="")]
public class Customer
{
[DataMember]
public string ID { get; set; }
[DataMember]
public string Name { get; set; }
} [ServiceContract]
public interface IService
{
[OperationContract]
[WebGet(UriTemplate="customers/{id}")]
Customer GetCustomer(string id);

[OperationContract]
[WebInvoke(UriTemplate="customers")]
Customer PostCustomer(Customer c);
}Here's more on this:
http://blogs.msdn.com/kaevans/archive/2008/04/03/creating-restful-services-using-wcf.aspx

 

[mmc]

Thanks again, Pavel. I'm not sure 3.5 is an option for me, but it
might be. If so, it sounds like UriTemplate is just the ticket. I'll
also check out the blog.

I appreciate the on-target and succinct help!