Understanding Representational State Transfer - REST

consider this...

REST -  approach for getting info/data from a Web using a designated URL that will return an XML file/streamed text  that describes and includes the content
a web page or a web service is the representation of resource

web method is a verb, e.g. get, put, post, delete etc.
class is noun, e.g. members, friends, articles

you call the verb on nous using url and get the state of a resource which you can represent in your way. the is generally be in xml form so that representation can be anything.

you can get details of your friend and use that in any way.

If you are aware of RPC, you would have getUser().
Same is implemented using REST using a URL like this http://example.com/users/
and hence the client would call it like this
user = new Resource("http://example.com/users/ABC")
 user.Get()

Ray I liked your answer but I am still vague on REST - so REST is a simple get/send concept i.e. specify values using GET method in your example above and return values depending on this. Unlike SOAP which is a complex contract - how is SOAP more complex?

I think If I had a small amount of advantages and disadvantages for SOAP and REST I would understand completely.

Cheers

Probably the best answer I can give you is the practical one.  I see hundreds of questions here at EE from people who are confounded by SOAP interfaces.  I never see one from somebody who does not understand a REST interface.  That ends the argument for me!

The Wikipedia article is not light reading - it requires some research and computer science background - but I have read it and I think it lays out the basics fairly well.
http://en.wikipedia.org/wiki/Representational_State_Transfer

The Stack Overflow discussion is pretty good.
http://stackoverflow.com/questions/76595/soap-or-rest

Comparison here:
http://www.ajaxonomy.com/2008/xml/web-services-part-1-soap-vs-rest

A good presentation:
http://www.slideshare.net/cesare.pautasso/rest-vs-soap-making-the-right-architectural-decision-1st-international-soa-symposium-amsterdam-october-2008-presentation

Extract from the site:
To summarize their strengths and weaknesses:
SOAP:Pros:
    * Langauge, platform, and transport agnostic
    * Designed to handle distributed computing environments
    * Is the prevailing standard for web services, and hence has better support from other standards (WSDL, WS-*) and tooling from vendors
    * Built-in error handling (faults)
    * Extensibility

Cons:
    * Conceptually more difficult, more "heavy-weight" than REST
    * More verbose
    * Harder to develop, requires tools

REST:Pros:    * Language and platform agnostic
    * Much simpler to develop than SOAP
    * Small learning curve, less reliance on tools
    * Concise, no need for additional messaging layer
    * Closer in design and philosophy to the Web

Cons:
    * Assumes a point-to-point communication model--not usable for distributed computing environment where message may go through one or more intermediaries
    * Lack of standards support for security, policy, reliable messaging, etc., so services that have more sophisticated requirements are harder to develop ("roll your own")
    * Tied to the HTTP transport modelComparison here:
http://www.ajaxonomy.com/2008/xml/web-services-part-1-soap-vs-rest

About the following sample url:
http://laprbass.com/RAY_REST_get_last_name.php?key=ABC&name=Ray

I would say that is totally against REST recommendations:
Countersense to SOAP, REST should not mention verbs (like get_last_name) in the URI. You should specify a resource.

This is more REST compliant:
GET http://yourdomain.com/REST.svc/persons  -> Get a list of persons
GET http://yourdomain.com/REST.svc/persons/A123  -> Get an specific person with ID A123
GET http://yourdomain.com/REST.svc/persons?lastname=Doe  -> Get list of persons with lastname=Doe

The resources are named in the URI, as "persons" or "A123". This is the trick of REST: name a resource and get the data (usually XML or JSON, but can be other).
Also you have POST, PUT and DELETE operations with similar style.