RESTful web services

Question

I am new to RESTful web services. We are taking the REST route for building our public web services to be consumed by out clients.And i had a few questions.

Are there any kind of limitation with pure REST webs services? and if yes then would a hybrid REST web service take care of those limitations?

I am thinking about using SSL + Hash Message Authentication Code (HMAC) in Authorization header for security along with IP based based filtering. what do you guys think about it?

Are there any good client side tools for testing? Currently i am using the following http://code.google.com/p/rest-client/

And what about some kind of client side code generation tool?

The following links are my source of info.

http://msdn.microsoft.com/en-us/library/dd203052.aspx

http://blogs.msdn.com/b/endpoint/archive/2010/01/07/getting-started-with-wcf-webhttp-services-in-net-4.aspx

Answer 1

The first thing to keep in mind is that a REST service should be stateless, which is very different when compared to a SOAP/RPC type of service interface. Using REST methodology requires you to rethink how you want your clients to interact with the service, breaking down the interactions into clear and concise method calls.

REST
+ Lightweight messages, very little overhead (other than the XML itself)
+ Easily readable results, can easily test with a web browser
+ Easy to implement
- Looser interface, loose type checking

SOAP
+ More rigid, with a strict contract definition
+ Plenty of development tools available.

Looking through the WCF MSDN documentation, WCF SOAP support was integrated from the start while REST support is a recently added feature. I myself am having a hard time finding documentation for authentication/security for REST services, as most of the documentation is directed towards SOAP.

Client side generation tools: I haven't come across any for REST services as REST doesn't define a service contract as SOAP does. WADL is an attempt to do that for REST services. http://en.wikipedia.org/wiki/Web_Application_Description_Language http://wadl.codeplex.com/

I'm interesting in reading more responses dealing with authentication and security, as I'm looking into that myself.

Answer 2

This is a good starting point of a WCF REST WebService:

REST / SOAP endpoints for a WCF service

(BTW: Stackoverflow has nice REST kind of urls.) You can test a REST service with just a web browser (Go to the url and get the XML or JSON). Fiddler is also good tool, and FireBug-plugin for FireFox. I usually make a thin service-interface project and a separate (unit-tested) logics-project.

For authentication I would first generate a Guid and a timestamp. Then based on those a hash (.NET supports SHA256 and SHA512). The Guid can be stored to server (database table) to map it some concrete numerical id. Then you can have a rest url like:

/myobject/1?timestamp=20100802201000&hash=4DR7HGJPRE54Y 

and just disable the hash & timestamp check in development environment (eg with AOP). With timestamp I would check that the stamp is between 15 minutes back and forward in time (=should be enough to prevent attacks).

Will your service be visible to the public/internet and is your client a jQuery or Silverlight -client? Then you still have a problem: You don't want to include a secret key in the client software code.

So you need to generate hash in server and some kind of cookie to store the client session. (This can be done eg with a separate login-page/application in a folder with different config-file.) I remember that this book did have something on the topic:

If you want to enable the HttpContext when using WCF, you need to set <serviceHostingEnvironment aspNetCompatibilityEnabled="true"> under <system.serviceModel> . Then you can check current user identity from HttpContext.Current.User.Identity.Name .

However, if you want to make a pure REST service then you don't use cookies, but a HTTP Basic Authentication coupled with SSL/TLS for each call.

I think that it's easy to make a client with just LINQ2Xml or jQuery so maybe client generation is not needed.

Or you can also have both, a SOAP and a REST interface, and use a service reference to make a client.

Answer 3

One thing to keep in mind is that you can take REST as a philosophy (everything should be reachable by a clean URL, without hidden strings attached) or as a dogma (you have to use PUT and DELETE even if that means a lot of hardship down the line).

The emphasis is on simplification - like using simple data types for params instead of stuctured pileups, nor clobering interface for superfluous reasons (like towing giant page "title" in a url), not using headers which are not well known and de-facto standard.

So, you can design perfectly RESTful interface using just GET and retain usability and testability from web browsers. You can also use any standard authentication methods or several of them for redundancy depending on your actual target audience. If you are making an app to run on a corpnet with standardized credentials and tokens you can continue using that. If you are doing something for very general access you can use combination of GET args and/or cookies - keeps your URL-s clean for 99.99% of users.

You can even serve both JSON and XML (like Google maps for example) and still be RESTfull, but you can't do full scale SOAP (complex input types etc). You can do limited SOAP - simple types for requests, always expressible as GET args, people still get WSDL for documentation.

Hope this paints flexible enough picture - the way of thinking above any strict dogma.