What gets classified as a RESTful Web Service

Question

So I currently have an application that calls a web service to retrieve data, where I do a basic HTTP GET on a url like so www.example.com/service.asmx?param1=1&param2=2 This returns some xml which I parse.

My question is, does this classify it as a RESTful Web Service? I am thinking no, but I'd like to know what makes it a REST web-service?

I know there are REST and SOAP web services, but what would the above case be classified as, simple HTTP GET Web service? or something?

Thanks, I am trying to match terminology to concepts, forgive me if this is a bit too elementary.

Answer 1

The direct answer to your question is No.

Breaking down what you have told us about your service I will discuss what is an is not RESTful about your solution.

HTTP GET on a url like so www.example.com/service.asmx?param1=1&param2=2

You are using an HTTP GET and are therefore using one of a limited set of verbs to access some kind of resource via a URI. This is RESTful and conforms to the uniform interface constraint as long as the server does not violate any of HTTP rules about what a GET is allowed to do.

Looking at the URL itself, it is not apparent what resource you are accessing and therefore it does hint that your URL space may not be structured in a way that is convenient for doing RESTful design. However, REST does not put any constraints on what your URL should look like (despite what soooooooo many people think), so there is nothing unRESTful with your URL.

This returns some xml which I parse.

Here is where your problems start. What I am reading implicitly in this statement is that the client knows how to parse the data out of your XML. This is a violation of the Self-descriptive constraint of REST. The http message should contain all of the information that is needed for the client to know how to process the response from a request. The media-type should tell the client what information is in the XML document. If your service returns application/xml then the only thing the client knows is that the document contains attributes and elements. If the client uses out-of-band knowledge to parse that XML then you are introducing coupling between the client and the server. One of the major objectives of REST is to eliminate that coupling.

There are a number of other constraints that a service must respect in order to be considered RESTful, but you do not provide sufficient detail about your service to say one way or another if it is compliant.

Answer 2

I don't think you will get a definitive answer on this. Both REST and Web Services are very confusing terms, now you combine them together.

REST could mean,

1. In strictest terms, the URL must represent a resource and proper HTTP verb (GEt/PUT/POST/DELETE) must be used. We have a convention here. It's spelled as ReST if it means this.
2. Any HTTP or web protocol as long as it uses query parameters and form post in request.
3. Any HTTP protocol. The request could be in an XML or JSON.

Web Services also have multiple meanings,

1. It used to mean SOA calls based on SOAP.
2. Then REST-style web services are introduced. It's basically SOA calls without SOAP. I even see people use the exact SOAP message without the SOAP header.
3. Some people believe WADL (equivalent of WSDL) must be used to classified as Web Services, especially in JAX-RS community.

Answer 3

This has been answered many times before on this site. You should take a look at Fielding's dissertation for the authoritative source on REST. His blog has some useful posts too.

URI representation has nothing to do with REST, but looking at yours, it looks like your service is likely RPC rather than REST. If you have only one URI for the entire service, which you make calls to via query parameters or headers, it's RPC, similar to SOAP.

The most important concept of REST is that your resources are discovered and navigated through hypertext. Your API must be a description of your media types. The only, single URI in your API is the entry point.

Answer 4

REST services are those services which generally conform to the following:

• Provide a identifier which accurately describes the resource being requested.
• Provide services which behave as expected GET requests are Idempotent, POST updates records, PUT creates, DELETE deletes
• Minimize state being stored on the server
• Generally tear down unnecessary complexity
• Over HTTP (though I've seen other implementations, they certainly are not RESTful in the traditional sense)

The reason your URL isn't as "restful" as it could be is it contains non-identifying information (such as .ASMX). Additionally some feel that adding url parameters is only appropriate for filtering. (but that doesn't mean using URL parameters isn't RESTful!)

If it seems there are no hard and fast rules to REST, you're on the right track.

Often RESTful services deal in XML, though again, that's no hard rule by any means either.

Answer 5

A direct answer to your question is I don't know.
The information you provided about your web service aren't accurate enough to get it classified as a RESTful web service.

REST is an architectural style (not a design or implementation technique), this means that you must follow its principles in the architecture of your software to get it classified as RESTful:

• Client/Server with a well-defined and uniform interface
  • Uniform identification of resources
  • Manipulation of these resources through their representation
  • Self-descriptive messages: each message describes how to process data
  • Hypermedia as the engine of application state: transitions between states occurs by following links
• Stateless
• Cacheability of resources
• Layered System

The #1 source you must consult prior to do anything RESTful is the Roy Fielding's PhD thesis, "the guy who invented REST" :-)

Note that REST does not specify URL schemes, but there are some common best practices about url schemes in RESTful architectures, like those used by Rails.