WHY Rest

Rails
61

You grew up speaking English, I guess. Not all languages work that way
and some languages you have to match up the cases, declinations and
conjurations as well as temporallities. There there’s languages like
Navaho which are so radically different you can’t really comapre them
with the Indo-European ones.

Navaho… that’s funny :slight_smile:

into libraries. I can build a controller around no methods except
‘method_missing’. I can build it with lots of exception handlers and
few “if” statements that do checking
(http://blog.codefront.net/2007/12/10/declarative-exception-handling-i...http://railsforum.com/viewtopic.php?pid=49600http://nullstyle.com/exceptional/
and others)

The point is putting things where they belong… Of course you can put
them where ever you want, but then other programmers are going to have
to chaise your code around.

John Kenneth Galbraith is one of the most clear, fluent writers of
technical and business English. In one of his books I encountered a
sentence that ran on for one and a half pages. I did a double take when
I realised it and went back and wrote the sentence out by hand,
decomposed it, and tried reformulating it a a number of shorter
sentences, with, alas, no success in preserving the clarity and impact
the original, and I do not believe that was due to any shortcoming in my
ability to handle the language. It was beautiful. It was graceful. It
was easy to understnad. But short it was not! (Now re-read this last
paragraph.)

That might be true for Literature.
However, for programming, short precise methods and controllers lead
to better designed and modular apps.

One “traditional” way of judging code quality comes from the days of
“goto-ful” programming. With “GOTO” you needed to remember where you
came from as you flipped back and forth though the lsitings. So if you
needed more than a places where you had your finger stuck in the fanfold
as a placemaker it was called a ‘more than five finger program’. On can
make the case that a single file is easier to scan that having ten
different controllers and having to grep to find which one has the
method, its all in one and your pinky finger just has to hit the ‘/’.

Well I guess its a matter of taste, but to tell you the truth, if I
saw a 120 method controller, I would simply think the programmer is in
a rush and didn’t have time to think thoroughly about the design of
the app, not that he prefers to search for a method name in just one
file… I know you where just trying to explain a possible argument,
but… come on now :slight_smile:

You’re arguing in a circle.

Not at all, this is regarding testing my friend, a crucial aspect of
software, that many people underestimate and later suffer the
consequences.
By encapsulating the functionality of your app into smaller units,
your testing becomes simpler.

REST lays down the guidelines for everyone to have a common
language. If I know you have a site about car rentals with all the
rates in xml form at the urlhttp://yousite.com/ratesI don’t need to
know anything else to access your data and add it to my site.

I’m sorry: are you saying you need REST to output (or input) XML?
I don’t think that’s the case.

Nop, what I was saying is that REST combined with Rails gives you an
XML interface, with very few lines of code.
Of course you can play around with XML in many ways, but I doubt you
can do it faster and so well structured,
as having a respond_to block that takes either html or xml, and
returns the output accordingly.

Discontent presents a challenge.

That is a good point, and exactly what DHH, the core team, and all the
contributors, have been fighting for in the last 3-4 years.
We have already changed the way software is developed, and will surely
keep improving. Rails, REST and BDD are part of this software
revolution.
Once they become mature techniques, we’ll jump onto the next big
thing, which most of us, probably can not yet even imagine, but will
surely come.
In the meantime, they are the best tools and design arquitectures that
we have.

P.S. For some obscure reason, Anton, you are making me an even
stronger believer in the REST philosophy, thank you :slight_smile:

62

In summary then - I think I like it, I want to use it, but I can’t
quite grasp it.
Tonypm

Here you go, this helped me understand the concept behind REST, or at
least I think I understand it :slight_smile:
The following is copy and paste from Wikipedia (http://
en.wikipedia.org/wiki/REST) I just put it here for convenience.

Representational State Transfer (REST) is a style of software
architecture for distributed hypermedia systems such as the World Wide
Web. The terms “Representational State Transfer” and “REST” were
introduced in 2000 in the doctoral dissertation of Roy Fielding,[1]
one of the principal authors of the Hypertext Transfer Protocol (HTTP)
specification. The terms have since come into widespread use in the
networking community.
REST strictly refers to a collection of network architecture
principles that outline how resources are defined and addressed. The
term is often used in a looser sense to describe any simple interface
that transmits domaine$B!>e(Bspecific data over HTTP without an
additional
messaging layer such as SOAP or session tracking via HTTP cookies.
These two meanings can conflict as well as overlap. It is possible to
design any large software system in accordance with Fielding’s REST
architectural style without using HTTP and without interacting with
the World Wide Web. It is also possible to design simple XML+HTTP
interfaces that do not conform to REST principles, and instead follow
a model of remote procedure call. The difference between the uses of
the term “REST” causes some confusion in technical discussions.
Systems that follow Fielding’s REST principles are often referred to
as “RESTful”.

Principles

REST’s proponents argue that the Web enjoyed the scalability and
growth that it has had as a direct result of a few key design
principles:
Application state and functionality are divided into resources
Every resource is uniquely addressable using a universal syntax for
use in hypermedia links
All resources share a uniform interface for the transfer of state
between client and resource, consisting of
A constrained set of well-defined operations
A constrained set of content types, optionally supporting code on
demand
A protocol that is:
Client-server
Stateless
Cacheable
Layered
REST’s cliente$B!>e(Bserver separation of concerns simplifies component
implementation, reduces the complexity of connector semantics,
improves the effectiveness of performance tuning, and increases the
scalability of pure server components. Layered system constraints
allow intermediaries–proxies, gateways, and firewalls–to be introduced
at various points in the communication without changing the interfaces
between components, thus allowing them to assist in communication
translation or improve performance via largee$B!>e(Bscale, shared
caching.
REST enables intermediate processing by constraining messages to be
selfe$B!>e(Bdescriptive: interaction is stateless between requests,
standard
methods and media types are used to indicate semantics and exchange
information, and responses explicitly indicate cacheability.

@Anton

Claimed benefits

Many of the statements below refer to REST in the specific context of
Web Services, as opposed to SOAP. REST was originally defined in
Fielding’s dissertation in the context of information and media
access. Fielding did not originally contrast REST with RPC.
Advocates claim that REST:
Provides improved response times and server loading characteristics
due to support for caching
Improves server scalability by reducing the need to maintain
communication state. This means that different servers can be used to
handle initial and subsequent requests
Requires less cliente$B!>e(Bside software to be written than other
approaches, because a single browser can access any application and
any resource
Depends less on vendor software than mechanisms that layer additional
messaging frameworks on top of HTTP
Provides equivalent functionality when compared to alternative
approaches to communication
Does not require a separate resource discovery mechanism, due to the
use of hyperlinks in content
Provides better longe$B!>e(Bterm compatibility and evolvability
characteristics than RPC. This is due to:
The capability of document types such as HTML to evolve without
breaking backwardse$B!>e(B or forwardse$B!>e(B compatibility, and
The ability of resources to add support for new content types as they
are defined without dropping or reducing support for older content
types.
REST detractors note the lack of tool support and the scarcity of
truly RESTful applications deployed on the web of today. Some claim
that REST is applicable to GET, but unproven for other state transfer
operations such as PUT. Fielding points out in his thesis that the
REST architecture was designed specifically for massive scale
hypermedia distribution, and not as a one size fits all architectural
style. Indeed what characterizes REST is the constraints that it
imposes on a REST based system. POST is often considered the only
necessary cliente$B!>e(Btoe$B!>e(Bserver state transfer operation, and
is treated as
a mechanism to tunnel arbitrary method invocations across HTTP.
Some REST systems have been deployed and gained tools support such as
WebDAV which uses not only GET and POST, but also established HTTP
methods like HEAD, DELETE, PUT as well as WebDAVe$B!>e(Bspecific HTTP
methods: PROPFIND, PROPPATCH, MKCOL, COPY, MOVE, LOCK, and UNLOCK.
One common stumbling block in the dialog on Claimed Benefits is
focusing too much on web browser support for REST. Gateways, caching
servers, proxies, and other REST connectors are the critical
components for system design and REST.
[edit]RESTful example: the World Wide Web

The World Wide Web is the key example of a RESTful design. Much of it
conforms to the REST principles. The Web consists of the Hypertext
Transfer Protocol (HTTP), content types including the Hypertext Markup
Language (HTML), and other Internet technologies such as the Domain
Name System (DNS).
HTML can include JavaScript and applets to support code on demand, and
has implicit support for hyperlinks.
HTTP has a uniform interface for accessing resources, which consists
of URIs, methods, status codes, headers, and content distinguished by
MIME type.
The most important HTTP methods are POST, GET, PUT and DELETE. These
are often compared with the CREATE, READ, UPDATE, DELETE (CRUD)
operations associated with database technologies:[2]
The following table associates several common HTTP verbs with similar
database operations, however the meaning of the HTTP verbs do not
correspond directly with a single database operation. For example, an
HTTP PUT is used to set the value of a resource and may result in
either a creation or update as needed.
HTTP CRUD
POST Create, Update, Delete
GET Read
PUT Create, Update
DELETE Delete
HTTP separates the notions of a web server and a web browser. This
allows the implementation of each to vary from the other based on the
cliente$B!>e(Bserver principle. When used RESTfully, HTTP is stateless.
Each
message contains all the information necessary to understand the
request when combined with state at the resource. As a result, neither
the client nor the server needs to remember any communication state
between messages. Any state retained by the server must be modeled as
a resource.
The statelessness constraint can be violated in HTTP using cookies to
maintain sessions. Fielding notes the risks of privacy leaks and
security complications that often arise through the use of cookies,
and the confusions and bugs that can result from interactions between
cookies and the “back” button in a browser.
HTTP provides mechanisms to control caching, and permits a
conversation between web browser and web cache to occur using the same
mechanisms as between web browser and web server. No layer can access
any conversation other than the one it is immediately involved with.

63

I want to add something here.

I can see sense in this ‘RESTFUL’ concept, adding the convention to
url routing,methods and controllers, is, as I see it, a meaningful
extension to the whole framework concept.

Saying ‘I dont use or need web services’ is not really an argument. I
dont either, but I might in the future, so the argument that says
adding web services later comes virtually for free is valid
futureproofing.

Having said that, I do relate to the original point being made. I
think some of the issue comes down to terminology and definition and
guidance. If you already have a grasp of this stuff and you are doing
web services then it probably makes sense. But to me, the term REST
is not tangible and borders on meaningless. As I understand it, REST
was itself really just a concept of stateless web page transactions.
Please correct me if I’m wrong. I cannot get this stuff concrete in
my mind and would love to see some rather more meaningful terminology
used that would make it clearer what is being referred to.

In one of my apps, I had to rework my Customer interface/controller
because I wanted to access the customer edit/add/lookup from within
another context using redbox popups. I decided to use REST resource
and I think I succeeded. Using the b-simple Restful rails pdf and
listening to ?DHH’s presentation several times, I was able to use the
path parameters in most of my links and forms. But I am still not
sure if I did CRUD or REST or what. I used the scaffold framework,
and then removed the responds to stuff cos I didnt need it. But my
structure now allows me to put it back in the future if necessary.

CRUD to me is something specific. But just what are ‘restful
resources’. I would really like to see the concepts grounded in a
more concrete way. Isnt a restful resource actually a CRUD
resource?? I can already hear you say - well no it isnt quite! Then
exactly what is it? In my understanding, I could make a restful web
service and not use the CRUD operations. But that would clearly not
be what Rails is meaning by restful resource. In some way it is
relating to the verb/noun url paradigm. But what has that got to do
with REST. I hope you can see my confusion here. I reckon that there
are several concepts lurking under the term rest which are implicitly
understood, but not explicitly tangible to those like me who have not
yet managed to fully enter in with their thought processes.

In summary then - I think I like it, I want to use it, but I can’t
quite grasp it.
Tonypm

64

tonypm said the following on 07/01/08 04:17 AM:

CRUD to me is something specific.

For me too.

But just what are ‘restful resources’.

Good question. I find the concept of a ‘resource’ a bit fuzzy.

I would really like to see the concepts grounded in a
more concrete way.

Me too.

Isnt a restful resource actually a CRUD resource??

Some peole here are saying everything reduces to CRUD.

I can already hear you say - well no it isnt quite!

Who? Me?

Then
exactly what is it? In my understanding, I could make a restful web
service and not use the CRUD operations.

Not difficult.

But that would clearly not
be what Rails is meaning by restful resource. In some way it is
relating to the verb/noun url paradigm.

Ah. Look at my above responses. I’ve made them deliberately short, but
they do illustrate that you don’t need ‘verb/noun’ sentences to be
intelligable. Its not that difficult to construct longer sentences
without either verbs or without nouns. Without both takes a bit more
effort.

But what has that got to do with REST.

Indeed.

I hope you can see my confusion here.

Yes.

I reckon that there
are several concepts lurking under the term rest which are implicitly
understood, but not explicitly tangible to those like me who have not
yet managed to fully enter in with their thought processes.

Me too.

In summary then - I think I like it, I want to use it, but I can’t
quite grasp it.

Me too.

Tonypm

–

In view of the stupidity of the majority of the people, a widely held
opinion is more likely to be foolish than sensible.
–Bertrand Russell, Marriage and Morals

65

On Jan 7, 2008, at 7:20 AM, Anton J Aylward wrote:

Good question. I find the concept of a ‘resource’ a bit fuzzy.

And this is key. Until you really get what a Resource is, REST in
Rails is just a naming convention.

A Resource is any thing in your application that has at least one
name (URL) that uniquely identifies it.

The fundamental change in RESTful thinking is to think in terms of
these things with names, and about the things they can do for us when
we ask them to.

Some peole here are saying everything reduces to CRUD.

When DHH brought REST to Rails, he got hooked on the REST == CRUD
metaphor. Sometimes (often) that works, but sometimes it doesn’t.
So it’s more than just CRUD, but that’s a good place to start.

66

Michael D. Ivey said the following on 07/01/08 10:44 AM:

these things with names, and about the things they can do for us when
we ask them to.

??
Isn’t that what we’ve bee doing for the last 40 years that I’ve been
programming? It was certainly the way I was taught. Do they teach
differently these days?

Some peole here are saying everything reduces to CRUD.

When DHH brought REST to Rails, he got hooked on the REST == CRUD
metaphor. Sometimes (often) that works, but sometimes it doesn’t.

Thank you. I suspect admitting that takes some courage :slight_smile:

For ages, a deadly conflict has been waged between a few brave men and
women of thought and genius upon the one side, and the great ignorant
religious mass on the other. This is the war between Science and Faith.
The few have appealed to reason, to honor, to law, to freedom, to the
known, and to happiness here in this world. The many have appealed to
prejudice, to fear, to miracle, to slavery, to the unknown, and to
misery hereafter. The few have said “Think” The many have said
“Believe!”
–Robert Ingersoll (Gods)

67

Hi guys,

I was rewatching the Railsconf 2006 keynote from David and its all about
REST.
He talks about the implementation of REST in combination with has_many
:through.
I think its a very good talk if you want to know more about REST.
Even without the slides you can follow a long quite well.
It gives a clear insight on how he was thinking at the time.

Its up for grabs here.
http://blog.scribestudio.com/pages/rails/

You want the David Heinemeier H. download.
And do yourself a favor and watch Martin F…

Now don’t go hammer the server all at once :slight_smile:

Regards.

Peter D.
http://www.railstation.eu/blog

PS
I will post this in ‘REST Style’ and ‘WHY Rest’

68

On Jan 7, 2008, at 1:45 PM, Anton J Aylward wrote:

When DHH brought REST to Rails, he got hooked on the REST == CRUD
metaphor. Sometimes (often) that works, but sometimes it doesn’t.

Thank you. I suspect admitting that takes some courage :slight_smile:

Not at all.

REST predates Rails, and REST is more than CRUD. The Rails
implementation of super-easy REST is very CRUD oriented, and it’s a
decent metaphor. It’s not an absolute, though.

I didn’t say REST didn’t apply everywhere. I maintain that by
definition, every web application can be modeled in terms of resources.

Just that it’s not necessarily CRUD.

69

On Jan 4, 3:03 pm, Anton J Aylward [email protected] wrote:

I’ve plugged “restful authentication” into my wiki and that’s fine
because its compartmentalized, but the rest of the wiki works entirely
on urls of the form
…
The authentication function is completely orthogonal to the Wiki space
so having ‘/login’ and ‘/register’ is not an issue.

You say “RESTful web design is cleaner and much easier to understand”
but I don’t see that. So many people say that and its getting to sound
like a “fashion” and “proof by assertion”. As I’ve said, there are blog
postings where people claim this simplification by don’t show the ‘how’
and don’t show it in a way that I can learn from the process.

I think the change from acts as authenticated to restful
authentication is a very clear example. Where the controller used to
have the #login and #logout methods in it, restful authentication
moved them into a new restful session controller. This seems at first
glance just like an extra file that isn’t really needed, but the major
change is the semantics, I think technoweenie asked himself “With
these extra methods what is the entity I am dealing with?” in asking
that question you get the answer “A session”.

That semantic shift to me is the thing that makes you think
differently about design. Now -in restful authentication- there is a
controller that allows you to create, read, update and delete accounts
which maps directly to the model and likewise you have a contrller
that allows you to create and delete a session. There is a clear
separation of concerns there which makes it easier to think about the
structure and behaviour of your application.

I know this is a very simplified example, but the thought process that
lead to the simplification of that plugin shows how to question the
complexity of your controllers. Prior to this change there was a lot
of debate about authentication being one of those examples where
restful controllers wouldn’t work.

James

70

Ahh brilliant, I was looking for this the other day!

On Jan 8, 2008 9:04 AM, Peter D. [email protected]
wrote:

Peter D.
http://www.railstation.eu/blog

PS
I will post this in ‘REST Style’ and ‘WHY Rest’

Posted via http://www.ruby-forum.com/.

–
Ryan B.

Feel free to add me to MSN and/or GTalk as this email.