What exactly is RESTful programming?

Question

What exactly is RESTful programming?

Answer 1

REST === HTTP analogy is not correct until you do not stress to the fact that it "MUST" be HATEOAS driven.

Roy himself cleared it here.

A REST API should be entered with no prior knowledge beyond the initial URI (bookmark) and set of standardized media types that are appropriate for the intended audience (i.e., expected to be understood by any client that might use the API). From that point on, all application state transitions must be driven by client selection of server-provided choices that are present in the received representations or implied by the user’s manipulation of those representations. The transitions may be determined (or limited by) the client’s knowledge of media types and resource communication mechanisms, both of which may be improved on-the-fly (e.g., code-on-demand).

[Failure here implies that out-of-band information is driving interaction instead of hypertext.]

Answer 2

I would say RESTful programming would be about creating systems (API) that follow the REST architectural style.

I found this fantastic, short, and easy to understand tutorial about REST by Dr. M. Elkstein and quoting the essential part that would answer your question for the most part:

Learn REST: A Tutorial

REST is an architecture style for designing networked applications. The idea is that, rather than using complex mechanisms such as CORBA, RPC or SOAP to connect between machines, simple HTTP is used to make calls between machines.

• In many ways, the World Wide Web itself, based on HTTP, can be viewed as a REST-based architecture.

RESTful applications use HTTP requests to post data (create and/or update), read data (e.g., make queries), and delete data. Thus, REST uses HTTP for all four CRUD (Create/Read/Update/Delete) operations.

I don't think you should feel stupid for not hearing about REST outside Stack Overflow..., I would be in the same situation!; answers to this other SO question on Why is REST getting big now could could ease some feelings.

Answer 3

Talking is more than simply exchanging information. A Protocol is actually designed so that no talking has to occur. Each party knows what their particular job is because it is specified in the protocol. Protocols allow for pure information exchange at the expense of having any changes in the possible actions. Talking, on the other hand, allows for one party to ask what further actions can be taken from the other party. They can even ask the same question twice and get two different answers, since the State of the other party may have changed in the interim. Talking is RESTful architecture. Fielding's thesis specifies the architecture that one would have to follow if one wanted to allow machines to talk to one another rather than simply communicate.

Answer 4

Those answers giving examples of linked resources is great but only half the picture.

So, imagine you're designing a website. You write a story,

I want to be able to search for an address by postcode so that I can choose a shipping address

Then you'd build the site to take the user on that journey and try and link the pages together in a workflow.

A website design that took them to an address lookup but then left them to copy the address into the clipboard and then return to the shipping address form wouldn't be very useable.

A REST API uses patterns we take for granted on the web for a machine-machine interaction.

The search for a postcode feature shouldn't be base/addresses/{postcode} and a collection comes back, even if each address links to a full address and some edit links, because that's a dead end; the API consumer would need to guess how to use the address.

Instead the motive for the feature should be built-in to the flow in which its used such that the journey ends back at the start:

1 GET /orders/123/shipping

  200 OK { Current shipping details + link to parent + link to address picker }

2  -> GET /orders/123/shipping/addresspicker

      200 OK { Link and form for searching for a postcode }

3   -> GET /orders/123/shipping/addresspicker?postcode=tn11tl

       200 OK { List of addresses each with link to pick it }

4    -> POST /orders/123/shipping/addresspicker?postcode=tn11tl&pickNo=3

        200 OK { Current shipping details + link to parent + link to address picker }

It's a user journey and at the end you can see the impact of the flow on the order.

The HTTP request/response isn't strictly part of REST but I don't think anyone has ever seen a non-HTTP REST application.

Now those URLs could be any set of characters, they're just identifiers, I made them pretty because they make sense to people. A machine would use the rel to work out what they do, not depend on a readable href.

Answer 5

What is REST?

REST stands for Representational State Transfer. (It is sometimes spelled "ReST".) It relies on a stateless, client-server, cacheable communications protocol -- and in virtually all cases, the HTTP protocol is used.

REST is an architecture style for designing networked applications. The idea is that, rather than using complex mechanisms such as CORBA, RPC or SOAP to connect between machines, simple HTTP is used to make calls between machines.

In many ways, the World Wide Web itself, based on HTTP, can be viewed as a REST-based architecture. RESTful applications use HTTP requests to post data (create and/or update), read data (e.g., make queries), and delete data. Thus, REST uses HTTP for all four CRUD (Create/Read/Update/Delete) operations.

REST is a lightweight alternative to mechanisms like RPC (Remote Procedure Calls) and Web Services (SOAP, WSDL, et al.). Later, we will see how much more simple REST is.

Despite being simple, REST is fully-featured; there's basically nothing you can do in Web Services that can't be done with a RESTful architecture. REST is not a "standard". There will never be a W3C recommendataion for REST, for example. And while there are REST programming frameworks, working with REST is so simple that you can often "roll your own" with standard library features in languages like Perl, Java, or C#.

One of the best reference I found when I try to find the simple real meaning of rest.

http://rest.elkstein.org/

Answer 6

RESTful (Representational state transfer) API programming is writing web applications in any programming language by following 5 basic software architectural style principles:

1. Resource (data, information).
2. Unique global identifier (all resources are unique identified by URI).
3. Uniform interface - use simple and standard interface (HTTP).
4. Representation - all communication is done by representation (e.g. XML/JSON)
5. Stateless (every request happens in complete isolation, it's easier to cache and load-balance),

In other words you're writing simple point-to-point network applications over HTTP which uses verbs such as GET, POST, PUT or DELETE by implementing RESTful architecture which proposes standardization of the interface each “resource” exposes. It is nothing that using current features of the web in a simple and effective way (highly successful, proven and distributed architecture). It is an alternative to more complex mechanisms like SOAP, CORBA and RPC.

RESTful programming conforms to Web architecture design and, if properly implemented, it allows you to take the full advantage of scalable Web infrastructure.