WHY Rest

[pankaj]

No, its not.
Unless you are just dong a CRUD.

Anything with more complex actions (a wiki: search, attach, roll-back,
access control …; a game: many functions!) you ARE going to have to
specify the actions and quite possibly the controller.

It seems that the REST philosophy is all about breaking things down to
where you can handle everything with CRUD.

For example, instead of an action ‘search’ you might create a resource
of SearchResult, which you would only need to Read (GET). Even though
it wouldn’t make sense to perform the other CRUD operations on a
SearchResult, you have still transformed it to focus on an object or
resource. For attaching an article, rather than having an ‘attach’
method for Articles, you would have an ArticleAttachments, on which
you could do all of your CRUD.

The presentation found at RailsEnvy “The Future of Web
Services” (http://www.railsenvy.com/2007/12/17/the-future-of-web-
services) gives some good examples of ‘how’ to make this switch. This
is found in the last 3rd of the presentation. It also addresses
benefits of a RESTful approach as it relates to web services.

I’m still not converted to the RESTful approach for plain web
applications but maybe it’s because I haven’t followed the “do it and
you’ll see” advice yet. It seems to me that the a user doesn’t or
shouldn’t care about the Model behind your web application, so it
seems following a CRUD approach for everything will lead to bad user
interface design. I think this relates to Jamis B.'s blog post
“Scaffolding’s Place” (http://weblog.jamisbuck.org/2007/1/26/
scaffolding-s-place).

I suppose I could still start the design from the user interface and
build the application in a RESTful manner. Maybe it’s just a matter of
organizing which interfaces belong to which controller. This seems
like it would require a lot of going out of my way to make my
application RESTful, but like I said, I haven’t really tried out the
RESTful application design approach yet, so I may be wrong.

What do you think?

–
Jimmy Z

[pankaj]

The need for a separate search controller would most likely apply if you
were CREATING new searches, as in a user wants to create and save a
search
for use later.

A search, at its simplist, should not be a create (post). A search is
almost always a GET, as you are retrieving a resource. Put simply…
searching can just call the index action, and the index action can just
grab
the search parameter.

/users/?q=hogan

def index
if params[:q].blank?
@users = User.find(:all)
else
@user = User.find_all_by_keyword(params[:q])
end
end

That would be keeping it simple. No need for a separate “search” action
in
the controller… leverage the way Rails does REST. A search is a
retrieval, so it’s a GET. Creating a search action that accepts a get
would work as well, but I like to keep it simple.

Plus, not using POST for searches greatly reduces some user stress, as
they
can hit the back button without the annoying “page expired” thing.

Just my way of thinking, others will disagree I’m sure.

[pankaj]

@Anton:

AHA! You, my friend, are finding exactly what I found about 2 months
ago.
You are doing things correctly, no doubt, but here’s what I find to be
the
key to REST:

REST is for web services, really. However, the advantates come into
play in
terms of organization. Just like Rails organizes your code into models,
views, and controllers. You don’t have to do that organization. You
could
just use ERB with no controllers if you wanted to, and do all your
finders
in the views. Would you? Probably not because it’s more organized.

One benefit the Rails framework has is that a developer can look at your
project, then look at mine, and pretty much know where to start.
Another
selling point of Rails is “convention over configuration.”

The core team adopted REST and has provided a mechanism to organize code
into this new convention. Once you adopt it, you write less code and are
more productive. These conventions are not something you absolutely
have to
follow. There is a lot of hype around REST in Rails, just as there was a
lot
of hype about Rails in general.

You’ve asked some great questions and started a great discussion. I’ve
provided my thoughts about how to architect something earlier, as have
some
others. You’re still asking for the “how” and the “why”. At this point,
I’m
not sure what you’re after. But I’ll take a guess as it was probably the
part I was hung up on:

You say that not every app is CRUD. I completely disagree. After doing
web
apps for near 10 years, I can assure you that every app I ever worked on
is
creating records, reading them, updating them, or deleting them.

• setting a student to be enrolled in a course? Creating an enrollment
  record
  (/enrollments -> :post, not /workshop/1/enroll_student/2)

• Search for an aparment?
  /apartments?city=chicago&bedrooms=4&lowprice=100000&highprice=300000

• Log a user in
  (/sessions => post), not /login/login

Adding custom methods to the REST routing is, in my opinion, there for
two
reasons:

1. to allow people not familiar with REST to “cop out”, or more
   nicely
   put, get stuff done without overanalysing
2. To provide methods that are ONLY needed on the web, like the NEW
   and
   EDIT view pages, or an advanced search form. You never need those from
   the
   webservice point of view, but you do need to show them to your web
   users.

Does that help at all?

[pankaj]

It looks like you folks are jumping into implementation details, so I
apologize for inserting this short philosophical discussion in the
middle of it, but if I don’t type it now, I probably never will.

I recently converted to REST after being a hater for a while, and I’m
glad I did. I think that the REST vs. Non-REST debate is similar to
writing valid vs. invalid (x)html, or even writing presentational vs.
semantic markup. Don’t get me wrong, I am NOT trying to offend anyone
here, or say that someone who is not using REST architecture might as
well be writing invalid, table-based html. Again, that is NOT what I
mean. What I mean is that the pro and con arguments for each of those
cases are fairly nebulous, and (insert controversy) when you take a
long step back, in the grand scheme of things, I doubt it has any
impact on the world whether my markup is valid xml or not. However, I
do write semantic, valid xhtml, because I personally like it better,
and think it’s A Good Thing To Do. Others think it’s too much of a
pain, and choose not to. I do, because I like it.

Why do I like REST? I like it for two reasons. One, because it
encourages me to compartmentalize my controller code into manageable
chunks, whereas left to my own devices, I’d probably write huge
sprawling messes. Two, because it forces me to spend more time
thinking about my application, how it all fits together, and what the
pieces really mean. That’s it! Those are the only compelling reasons
why I continue to use REST design principles! If those aren’t issues
for you, then don’t use it.

There are three points that were key to my adoption of REST that I’ve
not seen mentioned yet.

FIRST: REST goes beyond Rail’s map.resources implementation of it.
YES. Rest is bigger than Rails. Heck, if you really wanted to, you
could write a large, fully restful service with one controller and
some fancy routing. In fact, in some cases I have done that (which
blows away point #1 mentioned above). I would suggest picking up a
copy of O’Reilly’s RESTful Web Services book. I found the book to be
poorly written and inconsistent, but it was great to see REST
outside a Rails context. And it will help you discover my next point:

SECOND: RESTful URL’s do not necessarily have to be the ones generated
by map.resources. Recently I created an application that would render
graphs of the number of species discovered, per year, at any level of
the taxonomic tree, for any given date range. One of my URL’s, the one
for getting the graph images themselves, looks like this:

This route renders a PNG graph of all species discovered in Kingdom
Animalia between 1860 and 1923
http://host/graphs/kingdom:animalia/1860-1923.png

This route renders a SVG graph of all species in Family Hominidae
(that’s us!) between 1850 and 1960 (Neanderthal was discovered in 1856
I believe)
http://host/graphs/family:hominidae/1850-1860.svg

These URLs are RESTful, are routed to my GraphsController#show with a
custom route, and they’re beautiful. One of the more useful sections
of the O’Reilly book are their suggestions for creating URLs

THIRD: You need a REST buddy. REST is really hard to figure out by
yourself when you don’t fully get it. In fact, some times it’s really
hard to figure out even when you DO get it! Having a buddy to bounce
ideas off will be extraordinarily helpful.

I hope this is helpful,
-Ryan

[pankaj]

Nice Post Peter,

The advantanges of REST are like a sort of synergy. We can right apps
like we used to 10 years ago, or we can move on and use cool new
ways. How long would you take to decide the naming of basic
operations using non-REST ways? quite some time, specially if you are
in a big team of developers and each one has their own take on how
things should be done. REST, uses a convention that no one has to
dispute, because it just makes sense. We are going to use what the
HTTP protocol has had all along, but no one has used, the HTTP verbs
PUT and DELETE. That simplification is beautiful, and it doesn’t need
any ramp up time, of reading documentation about your site, to figure
out how it works.

Okay so simplicity because the naming of your basic operations (read,
write, update and delete) and already decided for you, and everyone
new to the project knows that, so you save time of explaining why you
coded things one way or the other.

Another advantage, you have to think harder about your design to make
it restful, you can’t just be adding methods left to right like
crazy. As soon as your controller goes over 20 methods, you have to
stop and think. Think about a better way to structure/design you
application. As you say Anton, not all applications are suited for
this design, but most of them are, it’s just that we haven’t done it
before and not sure how to tackle it. Maybe this helps, think about
the objects of you application, any object/noun can have its own
controller-model-view, which in most cases will lead to more
controllers but very simple controllers that you can understand in no
time. So, instead of facing a 100 method controller you have 10
controllers with 10 methods, and 7 of them are the same in all
controllers. Isn’t that beatiful and easy to understand?

Okay another advantage. Once you have 10 controllers instead of 1
huge one, you can test it much better. Let me refrase that, spec
it cause we like BDD, don’t we? So, you can write simple specs to
make sure each of those controllers does its job right, and that they
all comunicate with each other correctly, using for example, the all
might rspec Stories, which are freaking awesome So, your
application will become easier to spec and thus to maintain and extend
with confidence.

Another advantage. Information and continuous improvement of the
site. In my opinion an app, is never complete, it can always be
enhanced with new features, re-factored, made more robust and become
more useful by deleting features that are of no important use. Thus,
if we all use REST we will be able to share information with other
sites and enhance our own site with more information. This
information needs to be readily available and easy to access and
update. 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 url yousite.com I don’t need to
know anything else to access your data and add it to my site. I
already now yousite.com will give me all your rates
in xml form, and adding them to my database is trivial. In addition,
we can join forces just as easily, and I can add rates to your site by
going to yousite.com and filling out an html form or
simply sending you some xml data. This is very powerful, and I only
need to know the noun you used to represent your information.

As you can hopefully see, there is no one advantage about REST, its
more of a synergy of small things that make the development of REST
applications a happy and beautiful process, we like happy and
beautiful right? we don’t want frustration and reading long, cryptic
code/documentation, we want simplicity, get it done, and move on,
don’t worry be happy dude Rails has brought happiness to my life,
and REST has brought even more happiness to me and my co-workers,
thing about them too

Hope that helps

Raimond G.

[pankaj]

Ryan B. wrote:

Is it enough to not type something as horrible as:

link_to @topic.name, { :controller => “topics”, :action => “view”, :id
=> @> topic.id }

when Restful Routing gives you:
link_to @topic.name, topic_path(@topic)

I’m just starting rails, second week now, been into python and zope for
6 years. I actually find rails cool, but things like

topic_path(@topic)

takes me forever to FIND THIS convention. I need INSANE amounts of time
to find how everything is phrased, instead of just writing an extra line
of code.

Sorry for being off topic a bit here.

A

[pankaj]

On Jan 5, 2008, at 9:37 AM, Brian H. wrote:

A search, at its simplist, should not be a create (post). A search
is almost always a GET, as you are retrieving a resource. Put
simply… searching can just call the index action, and the index
action can just grab the search parameter.

…

Just my way of thinking, others will disagree I’m sure.

I agree with you 100%, Brian. The only time I’ve wanted to elevate
search to a separate controller is when it is doing multi-model
searches, and even then it was still a GET.

[pankaj]

On Jan 5, 2008 9:59 AM, voodoorai2000 [email protected] wrote:

If I know you have a site about car rentals with all the
rates in xml form at the url http://yousite.com/rates I don’t need to
know anything else to access your data and add it to my site. I
already now yousite.com will give me all your rates
in xml form, and adding them to my database is trivial.

This is one commonly-touted benefit that isn’t quite accurate. In
addition to knowing the URL, you need to know the structure and
semantics of the XML data. So while using it is obviously simpler
than if it were a WS-* service, it’s certainly not free.

That’s one of the promises of microformats. Of course, they haven’t
quite taken off yet.

Pat

[pankaj]

Well, technically you don’t if it’s a Rails REST resource and you use
ActiveResource. You could reflect on it like ARec, but I get your
meaning.

–Jeremy

On Jan 5, 2008 3:02 PM, Pat M. [email protected] wrote:

addition to knowing the URL, you need to know the structure and

–
http://www.jeremymcanally.com/

My books:
Ruby in Practice

Ruby in Practice

My free Ruby e-book

Site not found · DreamHost

My blogs:

Site not found · DreamHost

http://www.rubyinpractice.com/

[pankaj]

On Jan 5, 12:02 pm, “Pat M.” [email protected] wrote:

This is one commonly-touted benefit that isn’t quite accurate. In
addition to knowing the URL, you need to know the structure and
semantics of the XML data.

Very good point. On the other hand, in many cases the structure and
semantics can be obtained by inspection.

///ark

[pankaj]

Just do ‘rake routes’ and its all there.

[pankaj]

Bharat said the following on 05/01/08 04:07 PM:

Does anyone know of a book or a sample non-trivial application that is
solely based on creating RESTFul applications? I have RESTFul Web
Services Orielly book which has a broad based discussion. I would
prefer a more focused RailsSpace like book. The keyword is “non-
trivial”.

I found this, which seems to meet the ‘non trivial’ requirement.
It interested me because it was a refactoring and redesign, which is
what I’ve been trying to unearth in this thread. It seems to be a
‘proof by example’ rather than a ‘proof by assertion’

http://scottraymond.net/2006/7/20/refactoring-to-rest/

It is just another ‘talking point’?
http://www.sourcewatch.org/index.php?title=Talking_points

He gives numbers and lists of the ‘before and after’ and says “The
process was gradual…”

Maybe we can all ask him for more details.

–
The deepest sin against the human mind is to believe things without
evidence.
Thomas H. Huxley

[pankaj]

Does anyone know of a book or a sample non-trivial application that is
solely based on creating RESTFul applications? I have RESTFul Web
Services Orielly book which has a broad based discussion. I would
prefer a more focused RailsSpace like book. The keyword is “non-
trivial”.
Thanks.
Bharat

[pankaj]

Brian H. said the following on 05/01/08 10:49 AM:

One benefit the Rails framework has is that a developer can look at your
project, then look at mine, and pretty much know where to start.
Another selling point of Rails is “convention over configuration.”

I don’t think that’s a fair analogy, Brian.
I can read Latin, French, Spanish and a couple of other languages at
the ‘find my way around the airport and order a meal’ level. But I
can’t write or peak them.

I wrote compilers early in my career, and interpreters and DSLs. I know
how computer languages work. I’ve earned a living writing in about 12
different ones including SmallTalk and FORTH, but I find RPN hurts my
social life (too much RPN during the day and it spills over into the
night). So reading a language isn’t a big deal. Figuring out other
people’s code …well that depends. I’ve done maintenance on some awful
code in my time, again for a living. It instilled me with “I don’t want
anyone to think about me what I’m thinking about the guy who wrote that
code”.

Rails is nice; the ‘convention over configuration’ means things are in
the right place when you come to look for them. It makes it much easier
to understand than some ‘ad hoc’ application. Compare Instiki with
Socks, both wikis written in Ruby, one in Rails, the other ‘ad hoc’.

But you’ve tried to extend this to something else. I can read an
application written in RESTful Rails and understand it, but like reading
and understanding Latin or French, that doesn’t mean I could compose
one.

As for every application being CRUD, well I can see that if you’re stuck
with Rails and the Web and a database backed system you’re going to get
channelled that way. But people are using the Active* without database.

I can also imagine things like games where the CRUD might be used to,
for example, load the maps/terrains and flight characteristics for a
flight simulator, but the actual ‘flying’ isn’t CRUD.

–
If you are using Windows 2000, there is no chance that DES is your
weak link. The only justification for using 3DES is that it is cheap.
– William Hugh Murray, CISSP

[pankaj]

Wow. You guys definitely take these discussions pretty seriously. Each
person counter-arguing back and forth on every point the previous person
made. That is impressive how much the community cares about getting to
the bottom of “Why REST”. Interesting to see so many opinions on both
sides as well as the truthful “I just don’t understand yet…” posts.

I am curious to hear from people more in detail about something:

If you consider RESTful Rails approach to be useful, have you always
been convinced? If so, why did you jump on the wagon so quickly? If not,
what was the primary thing that contributed to you eventually being
convinced of the merits of REST.

If you consider the RESTful Rails approach to be not so useful and do
not plan on using it yourself in the future… have you ever tried the
RESTful approach? If not, what stops you from at least giving it a
chance for one application before making judgement? If you have tried it
and never intend to use it much again, what were the reasons that you
found it to be lacking. Any suggestions on how to improve it in the
future?

As for my personal take, I have been doing non-REST Rails for a long
time and I was frankly skeptical that it would be worth my time to
learn. I wasn’t planning on using it, I had watched the tutorials, read
the posts and it just wasn’t convincing. Then, I started work on a
project with a team member who was sold on REST and we developed in a
RESTful way for Rails 2.0 and now I am a believer as well. I won’t go on
rambling much longer but I concur with a lot of what the RESTers are
saying and I really enjoy sticking with the “convention” which in Rails
2 is fairly obvious.

[pankaj]

voodoorai2000 said the following on 05/01/08 11:59 AM:

Another advantage, you have to think harder about your design to make
it restful, you can’t just be adding methods left to right like
crazy. As soon as your controller goes over 20 methods, you have to
stop and think. Think about a better way to structure/design you
application. As you say Anton, not all applications are suited for
this design, but most of them are,

I seem to have an uncanny knack of picking the maverick ones then!
When I think back, the only completely CRUD system I ever did was an
accounting package in DB 4GL called Progress.

I’m old enough and scared enough that I wok out alternatives before
implementing. I’ve been known to run many test examples to find out hwo
compilers ‘work’.

Perhaps that’s why I’m comfortable with ‘constrained’ approaches (you
call it ‘convention over configuration’ but its had other names in
history) rather than an ‘infinitely rich colour pallet’ for my artists
brush. If you’ll pardon the analogy. I’ve found hat constraints means
focus.

So I get a lot of “yes, so what?” to that’s being said about structuring
for REST. The slicing and dicing of command and control and
responsibility isn’t new; I was taught it over 30 years ago.

it’s just that we haven’t done it
before and not sure how to tackle it.

LOL!

Maybe this helps, think about
the objects of you application, any object/noun can have its own
controller-model-view, which in most cases will lead to more
controllers but very simple controllers that you can understand in no
time.

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.

English, the subject - verb - object, way is either terribly sloppy or
terribly tollerant depending on how you look at it. Native speakers can
gloss and use idioms that are unintelligble to ESL, and non native
speakers can produce terribly fractured English with cases and tenses
all wrong but still be understood. Few other languages are that
‘tollerant’.

My point here is that even with the CMV, ‘there’s more than one way to
do things’. I can make my controllers skinny in number of ways; by
offloading code into the models, into the views, into the helpers or
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-in-your-controllers-rails-20-a-feature-a-day-2/
http://railsforum.com/viewtopic.php?pid=49600
http://nullstyle.com/exceptional/
and others)

So, instead of facing a 100 method controller you have 10
controllers with 10 methods, and 7 of them are the same in all
controllers. Isn’t that beatiful and easy to understand?

You remind me of the English language teachers or possibly the “Business
Communication” who advocate short sentences with strong verbs and
concrete nouns. They are asking you to ruin the language. Here’s a
pointer to a parody of one of the great works of our language with that
applied: The Gettysburg Powerpoint Presentation

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.)

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 ‘/’.

YMMV.

Okay another advantage. Once you have 10 controllers instead of 1
huge one, you can test it much better. Let me refrase that, spec
it cause we like BDD, don’t we? So, you can write simple specs to
make sure each of those controllers does its job right, and that they
all comunicate with each other correctly, using for example, the all
might rspec Stories, which are freaking awesome So, your
application will become easier to spec and thus to maintain and extend
with confidence.

You’re arguing in a circle.

Another advantage. Information and continuous improvement of the
site. In my opinion an app, is never complete, it can always be
enhanced with new features, re-factored, made more robust and become
more useful by deleting features that are of no important use.

And eventually become obsolecent …

Thus,
if we all use REST we will be able to share information with other
sites and enhance our own site with more information. This
information needs to be readily available and easy to access and
update.

That’s a non sequitor. It may or may not be true; it may or may not be
an advantage, but it certainly doens’t follow on from the previous
sentence.

One can, for example, add a RSS feed, or an RSS input, to a site with
little difficulty, without needing REST. One might even think of RSS as
‘just another “skin”’ defined by different template.

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 url http://yousite.com/rates I 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.

As you can hopefully see, there is no one advantage about REST, its
more of a synergy of small things that make the development of REST
applications a happy and beautiful process, we like happy and
beautiful right?

Actually no.
“The reasonable man adapts himself to the world; the unreasonable one
persists to adapt the world to himself. Therefore all progress
depends on the unreasonable man.”
–George Bernard Shaw

Discontent presents a challenge.

Hope that helps

   ____ ___ ____ _   _

/_/ | / | | | |/_
\ /_ | | | | || \ /
/ \ ) | | || | _ /
/ |/__|| || /

–
There are only 10 kinds of people in the world:
Those who understand binary, and those who don’t.

[pankaj]

On Jan 5, 2008 10:56 PM, Nathan E.
[email protected]
wrote:

been convinced? If so, why did you jump on the wagon so quickly? If not,
what was the primary thing that contributed to you eventually being
convinced of the merits of REST.

I gave REST a serious try with my last few projects because what I was
doing
in Rails just didn’t feel right. I felt that I was typing too much,
being
too verbose and in some cases not DRY, but not knowing why or what to
fix.

With REST, I now enjoy Rails development quite a bit more for the
following
reasons:

• Consistency across all controllers. I feel like I’m building a
  Rails
  site instead of a bunch of web pages handled by Rails.
• Much less typing: resources_url instead of :controller =>
  “resource”,
  :action => “index”
• Following from the above, code is much cleaner and easier to read /
  maintain.
• Occasional plus: RESTful webservices are almost free, just add XML
  output to the actions you want exposed.
• Helps me develop smaller controllers, more controllers, and fatter
  models, leading to better encapsulation and easier / better testing.

Of course, with Rails you can still drop back to the old way if you have
a
controller that just doesn’t fit the REST mold, there’s nothing wrong
with
that.

As Nathan says, you really can’t convince someone by pointing them to
reading material. You can know the ideas, know how to do it in code, but
until you actually do it once or twice will you know why REST is just a
good
way to go, and this is not Rails specific but for any website you happen
to
create.

Jason

[pankaj]

@Anton

Disagree all you like, but all Rails apps have the same structure, and
unless you’ve violated how Rails works, yes sir, I can pretty much tell
what
you were doing. Again, that’s if you followed the conventions instead of
hacking up your own way of doing things. That’s a far cry better than
“Bob’s PHP framework created by company XYZ”. Frameworks, in general,
make
apps more maintainable. The more conventions the framework has, the
more
maintainable the code is. Taking things to the next level of convention
with REST results in lower amounts of code, which is less to maintain.

I can also imagine things like games where the CRUD might be used to,
for example, load the maps/terrains and flight characteristics for a
flight simulator, but the actual ‘flying’ isn’t CRUD.

The flying in a flight sim is CRUD. You are Reading and Updating some
resources. No matter what you do in application development, you can
think
if it in CRUD, and that’s what REST in Rails asks you to do. Anything
you
can come up with can be modeled that way. Just because it doesn’t appear
that way to you doesn’t make it false.

If I change a method on an object, that’s technically an UPDATE.

plane.increase_speed (update)
plane.current_speed (read)
plane.altitued (read)
plane.increase_altitude (update)

You can argue against if you want, but that’s the way people who have
embraced REST think of it.

[pankaj]

Brian H. said the following on 06/01/08 12:38 AM:

plane.altitued (read)
plane.increase_altitude (update)

You can argue against if you want, but that’s the way people who have
embraced REST think of it.

THANK YOU ! ! ! !

At last, something tangible instead of the same old hoary oft-quoted
examples.

THANK YOU ! ! ! !

(Only 4 exclamation marks. I take not of what pTerry said.)

Now I just need a brainstorm to see how that maps to what I’m doing.
What I’m faced with is that apart from the web services of ‘list’
there’s not a lot of public-facing functions for the parts of a wiki.
Even the models themselves aren’t actually public facing since the sole
‘resource’ is the wiki itself.

Another way of looking at this: an admin interface might let you get at
the individual tables and bypass referential integrity - or patch it up
for maintenance purposes. But you don’t want a publicly exposed URL
that can be hacked. (If you want I’ll start a branching thread about
security trivia.)

In this example, the GUI may have buttons for the planes controls, but
there are other ‘resources’, internals like fuel and internal state
(“Houston, we have a main bus A undervolt now, too… It’s reading 25
and a half. Main bus B is reading zip right now… We got a wicked
shimmy up here.”) Well not quite. But fuel consumption and how it
affects COG are flight characteristics are internal functions not
something that’s exposed as a URL.

This is is one of the conceptual issues I’m facing.

Or let me put it another way. There is a flying technique where you
don’t touch the throttle. The user interface is the joystick.
joystick.forward is an exposed function. The ensuing plane.tilt causes
a time dependent plane.increase_speed and plane.decrease_altitude and
plane.have_wings_ripped_off_at_roots and plane.crash_onto_ground, but
those are not exposed by any URL. Or at least in a good design they
are not, since the interface is only there to model the available
controls.
Note also that some of those functions are timed and not a response to
the user clicking a button.

Now my analogy only goes so far because while plane engines (or at least
the ‘small’ prop-driven ones I’m familiar with) do have engines which
run at ‘constant revs’ (unlike auto engines), they also have throttles
(how else would you start them up?).

But I’m sure we can come up with a ‘resource’ that not only must not
have any functionality exposed, but one whose operational integrity can
be subverted by using a URL with suitable parameters.

Lets face it, that

    map.connect ':controller/:action/:id'

or its equivalent is a security risk.
(If you don’t see why then good for you; you’re one of the ‘good but
naive’ guys.)

The only freedom which deserves the name, is that of pursuing our own
good in our own way, so long as we do not attempt to deprive others of
theirs, or impede their efforts to obtain it.
–John Stuart Mill (On Liberty, 1859)

[pankaj]

Now I just need a brainstorm to see how that maps to what I’m doing.
What I’m faced with is that apart from the web services of ‘list’
there’s not a lot of public-facing functions for the parts of a wiki.
Even the models themselves aren’t actually public facing since the sole
‘resource’ is the wiki itself.

Don’t think of REST as public facing resources.

Maybe I want to modiffy the wiki using a nice GUI client or an OSX
widget
instead of a web interface. You expose all the CRUD features of your
wiki
via REST, wrap them with http basic authentication, and then you have an
api
other devs can extend to provide nice features to your wiki.

Imagine a product page on your wiki. When you tag a new release in SVN,
the
changelog gets posted to the appropriate spot on the wiki.

Imagine an integrated ticketing system that could send FAQs up to your
wiki
based on helpdesk calls.

Web services / REST isn’t just for the public. It’s for you!

As for REST and a flight sim, it’s not something I’d do on the web with
a
stateless bit of code. That’s really something you want a client-side
thing
to do so you can maintain states, use events, etc. You probably could do
it
with Rails, but I wouldn’t. I dont’t think that’s the right tool for the
job.