Have been reading up a bit on REST (Representatable State Transfer) and not unsurprisingly I'm struggling to identify what it actually means.

Let me explain

Recently I built a planning application system that while showing most of its information through access has links to the online planning application record system.

These links are created when the web page is accessed simply by concatenating a standard url string with the string of the planning application number. It works really well with minimal upkeep with the planning application working like a key between the access database and the online web page.

In this way the online form very much becomes a subform of the database.

I'm curious is this what REST is??
Is the online page I'm linking to effectively adhering to the principles of REST

All the reading seems to be particularly verbose when talking about something which I suspect is actually quite simple.

Another analogy to Database Design would be where you are linking to files on your computer. You could store the directory for each file individually in a separate field in a "File Table" alternatively you restrict file storage to one single directory and store a single file directory parameter and join it to the unique filename when the users needs the file.

In this analogy I'm inclined to believe that the second method could be said to be RESTful.

Can anyone with more knowledge than me enlighten me to whether I'm correct or not? Thanks

First of all I must state that I've studied this briefly and I had a tough time understanding it (if I ever did). But I'm writing since no one else has. It''s an explanation from a complete layman and therefore may be nonsense :).

The reason that it's hard to understand REST is because it's an architecture. In other words it defines a style in which to implement web services rather than defining a protocol (such as SOAP). I think of a web service a bit like an object for performaning a certain task. You issue an instruction, it does something and you get a response.

So you know that REST is an architecture for providing web services. One important aspect of REST compare with other web service methodologies is that it uses standard network protocols e.g. html.

Suppose we are carrying out a transaction. So the idea is the client makes a request to the web service (via a URI) and the response is a URI which is a new set of options if you like. So the client has reached a new point in the transaction it is trying to perform.

The web service does not hold any info about where it is up to in the transaction so the client must know where it's at (with the current URI).

All resources of the web service are provided as URIs. So each invoice for example will have a unique URI.

Standard http operations (GET, PUT, POST, DELETE) are used to manipulate the resources.

Here's an example. Suppose we have a simple web service that maintains the status of whether I'm available for work or not as a boolean. Then I could set my status as available like this:

PUT "true" to http://chris.workstatus.co.uk/available

Or unavailable:

PUT "false" to http://chris.workstatus.co.uk/available

To get my status:

GET http://chris.workstatus.co.uk/available

Here's another link with some examples.
http://www.xfront.com/REST-Web-Services.html

You might like to google "REST versus SOAP" as although they both provide web services, they are fundamentally different in their implementation. There are pro/cons for each.

hth
Chris

Thanks Chris I think I was on the right track and it does seem that our online planning system is RESTful. In that it isn't so much serving up stored pages but querying the database and then delivering the information in a standard format.

It names the page according to the planning application. REST to me seema remarkably similar to a relational database.