views:

430

answers:

7

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.

+2  A: 

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.

altCognito
This is incorrect. REST is a formally defined architecture. No where in its specification does it mention HTTP. Also, the stateless constraint is absolute, not just 'minimal'. The identifier itself doesn't describe the resource - URIs can be represented however you like. The resource's media type is only described in the API. GET/POST/PUT/DELETE usage has nothing to do with REST - this is just proper HTTP usage. "RESTful URLs" is a nonexistent concept. There ARE hard and fast rules to REST. If you violate the constraints of REST, your API simply is not REST and should not be called as such.
Wahnfrieden
I think you would have difficulty pulling up a link to a formally definition of the architecture (IE, a specification) The best you'll find is the original dissertaion by Fielding: http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm - which, is useful and specific for an academic, but isn't a formal spec. There's what Fielding defined, and REST in practice.
altCognito
No. There is what Fielding defined and a thousand mis-interpretations. This idea that you can implement just some of the constraints and then claim it is "REST in practice" is bullshit. To claim that Fielding's dissertation is not a formal spec is crazy. Just because it does not define a specific architecture or implementation does not make it imprecise.
Darrel Miller
REST in practice which does not conform to Fielding's constraints as detailed in his dissertation is simply not REST. Sure there are developers out there who do not understand REST and misuse the term - that's no excuse for propagating inaccuracies. There are real benefits to understanding REST and following its constraints. Fielding is not lost in academia, far away from reality - he not only participated in building HTTP, but he's also currently employed at Apache.
Wahnfrieden
Actually I believe he is employed by Day Software but he is actively involved in the Apache Software Foundation. For sure he spends his time working on real products for real customers. Definitely not stuck in academia.
Darrel Miller
I'll agree that following RESTs architectural style constraints yields real benefits. There's a reason some services are called more RESTful than others. I'm sure you both consider that an abomination as well, but it more accurately reflects reality: Meeting every guideline of REST is difficult, and I tire quickly of architectural astronauts who try to force expensive, time consuming implementations for the sake of REST purity.
altCognito
Which constraints in particular do you feel are unnecessary? Anyway, we are not advocating REST for every application, just the correct usage of the term. I feel like it's the ones who don't understand REST who try to push it on every service.
Wahnfrieden
First let me assure you that I write real code that gets delivered to real customers, regularly using a RESTful architecture. The reality is that REST is not right for all situations. There are lots of alternatives. What I tire of is people using the term REST when constraints are being violated. Feel free to implement your distributed services using XML over HTTP, just don't call it REST. Abusing the term leads to confusion that we see here all the time at Stack Overflow. People can't tell what is REST and what is not because everyone is calling anything that uses Http and an Url REST.
Darrel Miller
Well, that's bordering on pedantic, and really, gets back to my point that REST has lost it's original meaning. Which should be no big surprise, it's been almost a decade since the dissertation was written, and was essentially "lost" as a "architectural style" until recently. But, I honestly, I still appreciate the links to Fieldings recent musings on the topic +1 to your answer. Time for me to go for the day though, good luck.
altCognito
It's been even longer since the HTTP spec was written, and it seems like it took until now for most people to start caring about all that it offers, e.g. proper usage of its verbs, clean and descriptive URIs, etc. In other words, what many people are mistaking for REST.
Wahnfrieden
You think this is being pedantic, go searching for discussions on the HTTP-Range 14. Way smarter people than me have been arguing for years on what a web Resource is and whether HTTP can point to cars and dogs or not?
Darrel Miller
A: 

See here for prior relevant discussion regarding query strings in RESTful architecture:

http://stackoverflow.com/questions/390604/detail-question-on-rest-urls

klochner
two downvotes and no comments, just for linking to a SO article? You have to be kidding.
klochner
My reasons for disliking that article are contained in my comments on it. You didn't provide anything more than a reference to it, so I didn't feel a need to comment, sorry.
Wahnfrieden
The question asks "What gets classified as a RESTful Web Service?" and you point to a question that talks about query strings. The two issues have very little to do with each other.
Darrel Miller
I didn't find the link relevant, because despite its title, it does not actually address this question, in my opinion. Besides, your answer is more appropriate as a comment on the question.
Wahnfrieden
Darrel, you implicitly addressed query strings vs. paths in your own response.
klochner
Errr, I don't think I did. At least I can't find where I did.
Darrel Miller
+3  A: 

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 it's 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, by the way there are some common best practices about url schemes in RESTful architectures, like those used by Rails.

Carmine Paolino
URI naming schemes have nothing to do with REST. Your linked PDF is not based on authoritative sources, and is not an accurate depiction of REST - REST is not about CRUD, for one. A GET request with parameters has nothing to do with REST - it's just HTTP, which is not part of the REST architecture specification.
Wahnfrieden
Downvote for a correct answer (REST doesn't specify how a GET response must be performed) and a pdf about best practices? Does it makes sense?
Carmine Paolino
The article is only about HTTP, it doesn't actually talk about REST concepts, except for mistakenly calling HTTP REST.
Wahnfrieden
Just because REST doesn't specify something does not mean that it is considered RESTful.
Wahnfrieden
If it doesn't violate any REST rule, why can't be considered RESTful?
Carmine Paolino
clarified and edited
Carmine Paolino
REST doesn't specify anything about CDROM drives - does that make my computer RESTful? ... REST includes a set of constraints, which must be followed. If you don't satisfy these constraints, it is not REST. Simply using GET is not sufficient for satisfying the constraints.
Wahnfrieden
I learn new concepts every day... answer entirely rewritten :-)
Carmine Paolino
Thanks, glad you looked into it, though this isn't a very helpful answer still and please don't use emphasis so much :D
Wahnfrieden
A: 

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.
ZZ Coder
REST has nothing to do with URI naming conventions or HTTP. You're mistaking "REST" for "HTTP" in your points. The spelling of REST is irrelevant, and Roy Fielding himself writes it "REST" anyway.
Wahnfrieden
The only reason these issues are confusing is because somewhere in the past few years REST became a new buzz word and all the vendors started converting their frameworks to "support" REST and the Web 2.0 sites started making APIs that they labelled "REST" because it was synonymous with "simple and easy". Unfortunately, the majority of these implementations failed to grasp the point of REST and in doing so have really confused a whole lot of people.The first major public API that has really got it is the Sun Cloud API. Netflix isn't too far off either.
Darrel Miller
It also continues to propagate through marketing teams which feel labeling their API "REST" will make it more attractive to developers. See Flickr's, which isn't REST at all, and I'm sure someone there knows it.
Wahnfrieden
+1  A: 

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.

Wahnfrieden
+6  A: 

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.

Darrel Miller
- How could one produce a restful web service that can reply to a client in a non-coupled manner? is is supposed that the client is able to process the answer; doesn't it urge us to structure the resource in a concrete form?
lmsasu
- "There are a number of other constraints that a service must respect in order to be considered RESTful" - where could I find these constraints stated?
lmsasu
A: 

Hi All,

I am new to this RESTful webservice,pls help me how to parse the response data xml/json

any sample code or links

Thanks in advance.

naveen