Rich's "The Value of Values" and REST

[Conrad]

Hi Everyone... Quick question about Rich's latest talk:

In it he eloquently argues that "you don't want to systems to communicate with each other by calling each other's methods. Instead it is better to just move values between systems that can also be queued."

It occurs to me that RESTful web interfaces essentially hide a big chunk of state behind a bunch of methods (i.e. the URIs you can GET/PUT/POST to.)

Am I right in thinking that Rich's talk is an argument AGAINST RESTful design? It seems to me his talk would suggest the best interface would almost be a SOAPy interface, where all communication is to a single URL. (Of course unlike SOAP the calls wouldn't consist of method invocations but instead consist of a stream of values.)

Is this right?

[László Török]

Hi,

in my understanding, RESTful system design (as described in Roy Fielding's dissertation) does not advocate hiding any state "behind a bunch of methods". :)

In REST, application state is carried by the representation that is passed back and forth between the server and the client.

It seems to me that a "truly" RESTful system design is very much in line of what Rich was talking about.

Las 

2012/8/15 Conrad <drc...@gmail.com>

--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clo...@googlegroups.com
Note that posts from new members are moderated - please be patient with your first post.
To unsubscribe from this group, send email to
clojure+u...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

--

László Török

[Raoul Duke]

i think per HTATEOAS, the methods are baked into the representations
that are transferred, as URLs. i mean, you gotta have methods
*somewhere* *somehow* that can *do stuff*, in an
application-context-sensitive manner.

[Warren Lynn]

Rich was promoting functional programming. I can see functional programming has its benefits, but you will need mutable states eventually somewhere to do useful things. Functional programming just tell you to constraint yourself when using mutable states. It's not like mutable states are to be avoided by all means. I mean, do you want to get a copy of Google's internal state so you can send it back to Google next time along with your search string, and hence make Google search functional? That is neither practical nor desirable.

Also, my impression is some of Rich's high profile speeches (and some of his partner) tends to stress the message he wants to deliver by simplifying things to an extent that I feel is in the danger of distorting the reality (because other important things were left out). I still think many of his points are very insightful, I just enjoy the speeches better by standing back a little bit. Just like when you watch a talk show, there are many good insightful comments about life and politics and etc, because they exposed something you may have never thought about, but I don't ask "it is true?" on each of those comments. :-)

[Timothy Baldridge]

It seems to me that a "truly" RESTful system design is very much in line of what Rich was talking about.

This is completely correct. Let's take the common method "GET" for instance. According to REST philosophy, GETs should be 100% cache-able (and therefore they are actual values). We can "disable" the HTTP caches simply by giving different parameters to the get query:

>> GET /person/123?latest=true&rnd={insert random guid here}

{:name "John" :gender "Male" :id 123 :timestamp 1002313}

>> PUT /person/123
>> {:name "James" :gender "Male" :id 233}

/person/123/1002314

>> GET /person/123/1002314

{:name "James" :gender "Male" :id 123 :timestamp 1002314}

>> GET /person/123/1002313

{:name "John" :gender "Male" :id 123 :timestamp 1002313}

>> GET /person/123?latest=true&rnd={insert random guid here}

{:name "James" :gender "Male" :id 123 :timestamp 1002314}

The above perfectly follows what Rich discussed. No information is ever lost. We have time explicitly defined in the timestamp, and we can always get the latest version of a value by passing in a random guid to invalidate the HTTP caches.

If you read up a bit more on REST you'll find that it deals allot with the avoidance of mutable state, which is exactly what Rich was suggesting.

Timothy

[vemv]

There are few -if any- concepts attached to REST; it is just a low-level, "ideologically"-neutral technique. There is more than one way to do it, hence you really can't talk 'against' it any more than you can talk against hashmaps, for instance.

That said, getting RESTful design right is pretty hard, state-wise. Sofisticated usages will require substantially uglier URIs than the fancy examples that get promoted, and compromise the architecture of the provider system. Think iterators, promises, etc.

[Stuart Halloway]

> Rich was promoting functional programming. I can see functional programming has its benefits, but you will need mutable states eventually somewhere to do useful things. Functional programming just tell you to constraint yourself when using mutable states. It's not like mutable states are to be avoided by all means. I mean, do you want to get a copy of Google's internal state so you can send it back to Google next time along with your search string, and hence make Google search functional? That is neither practical nor desirable.

It is practical, and desirable, to make a complete (albeit lazily realized) value of e.g. entire databases available to any process in a system.

Stu

[Rostislav Svoboda]

> I just enjoy the speeches better by standing back a little bit.

Actually I'm quite annoyed that Rich doesn't say anything about how
important is to be able to forget facts, irreversibly filter things
out and reinvent the wheel again. Imagine a huge database full of
facts you're simply not interested in. What is it good for?

BTW there are stories about people not been able to forget. They
remember every useless trivia, quarrel or conflict they ever
experienced and they have to go over and over every good or bad memory
just to recall things like "Did I meet you before or after 2005?".
Pretty much like our databases: "select * from the
5TB-useless-stuff.txt what happened between BIG-BANG and NOW"

Bost

[Craig Brozefsky]

Rostislav Svoboda <rostisla...@gmail.com> writes:

>> I just enjoy the speeches better by standing back a little bit.
>
> Actually I'm quite annoyed that Rich doesn't say anything about how
> important is to be able to forget facts, irreversibly filter things
> out and reinvent the wheel again.

That was mentioned in the talk actually, as part of the bookkeeping that
comes with such histories.


--
Craig Brozefsky <cr...@red-bean.com>
Premature reification is the root of all evil

[Softaddicts]

A 12 billions market has been created just to address the need for bookkeeping
historic data, it's called business intelligence (BI).

Never heard of data warehouses and OLAP tools ? Many businesses use these
if they can pay for them....

These things are cumbersome to implement, you have to extract data from your
operational systems following a tight schedule (otherwise data gets obliterated
before you can grab it) and import it in a BI backend and get it reorganized.

Data to be dumped in the BI backend has to be selected, frequency of uploads,
.. You cannot be certain that you grabbed everything that
matters, not knowing what future needs analysts may have. You also need a separate
infrastructure to run the whole gizmo.

Having a database where values can be read at will, replicated transparently
and scale easily where you do not loose any fact would simplify BI implementations a lot.
Most probably the whole migration process could be tossed away. The only
remaining need would be the creation of meta data needed for the analysis tool.

It may be important for us to forget past facts, otherwise we would go crazy but
may I point out that our brains never forget anything, we happen to have
neural cells specialized to hide past facts but these can be recalled.

As you age, this mechanism fails from time to time and can bring you back fresh souvenirs like if events happened yesterday.

:))))

Luc P.

> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clo...@googlegroups.com
> Note that posts from new members are moderated - please be patient with your first post.
> To unsubscribe from this group, send email to
> clojure+u...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
>
--

Softaddicts<lprefo...@softaddicts.ca> sent by ibisMail from my ipad!