"REST" and "RESTful".

[drm604]

I'm learning Ruby, and specifically "Ruby on Rails". The concept of a "RESTful" app seems to be important, at least to my employer.

I'm trying to understand the concept of "REST". Googling around the web, I can't really find a clear explanation. It strikes me as another poorly defined buzz word.

According to Wikipedia, HTTP and the Web itself are RESTful. Not much help there.

The acronym "REST" stands for "Representational State Transfer". Okay, so we're talking (I think) about about moving representations of states from point A to point B. How can we represent a state with anything other than a "representation"? It seems like a tautology.

So, literally it means "moving around information". I guess that vindicates Wikipedia, but it also reduces the term to meaninglessness.

But let's set aside the rants about the poor use of language. From what I can tell, in current real world usage "REST" usually involves the use of XML... but not necessarily. The "but not necessarily" again reduces it to meaninglessness - "it either uses XML or it doesn't". :crazy:

Okay, in the context of my current employment it does seem to involve XML but I'm trying to understand how and why.

Apparently, at least in the context of what I'm doing, it means making available via a URI, an XML representation of the data which is extracted from a DB on the server. This representation is not intended for the end user but is used in another URL to present the data as, for example, a grid.

What is the purpose of this? I'm used to using PHP to extract the data from a database and then including it in a generated HTML page, possibly utilizing Ajax and Javacript. Rendering it as XML on a separate URL first seems to be an unnecessary intermediate step. If you are presenting the data to an end user who requires XML then it would make sense, but what's the sense in having a step where it's represented this way when the intended user interface is a web page that includes the data in, for example a grid?

What am I missing here? Am I understanding it correctly?

Also, what about changes to the database? Do updates, deletes, and inserts require going through an intermediate XML representation?

[drm604]

1. No help here I guess.

:shrug:
I've posted in forums on appropriate technical websites and so far no one on any of them have been able to describe it in any meaningful way. Mostly they just point me to that useless Wikipedia entry. Maybe it is just a poorly defined buzzword. The RESTful emperor has no clothes I guess.

[ManiacJoe]

2. XML is good for transporting structured data.

While being a bit verbose, XML is a format that allows data to be moved from place to place without the need for the two places to be binary compatible. Other text formats, like CSV files, can also serve the same purpose; but XML allows for complex structures beyond rows and columns.

In your example, you would query the service at the URI and get a response of nicely formatted XML data. The app receiving the data then parses the XML and does what it needs to with the data, one example of that being to display the data in a grid. The example of a grid was probably chosen since you can get that for almost free in most browsers with the help of a little CSS work.

The purpose of sending the data from the service (as XML or any other format) instead of the service rendering the data in an HTML wrapper is to uncouple the service from the presentation of the data. The service just serves the data while the receiver does what it needs to without either knowing about the workings of other. This can easily look like too much overhead if you know that the only receiver of the data is going to be a particular web browser.

The intermediate XML is used for moving the data between the web server and client. If the db updates are being triggered from the client requests, then since the data was sent to the client in XML, it is reasonable to get the data from the client in XML.

[drm604]

3. Certainly it makes sense if you're planning to make it available to more than one receiver

but, as you say, it looked like to much overhead to me when the only use is to render it on one particular web page.

In any case, I've found a definition of REST that makes sense and has clarified things for me. XML isn't really part of the definition. What REST means, at least in the context of an MVC framework, is that the models only have four methods, get, put, post, and delete. Of course, browsers don't even support put and delete but I suppose you can emulate them with post.