On 28/11/06, Mark Baker <[EMAIL PROTECTED]> wrote:
>
>
>
>
>
>
> On 11/28/06, Steve Jones <[EMAIL PROTECTED]> wrote:
>  > Not from the perspective of the consumer, when I see a URI that
>  > includes something like "drawGraph?xData=fred&yData=pointless" then
>  > I'm calling drawGraph with those parameters.
>
>  And if the publisher of the *same* functionality used this instead;
>
>  http://example.org/kdjfalkjdfnawkflaudfnakjsdnfalufh
>
>  then what would the operation be there?

Incomprehensible to any rational person?

>
>  > I don't care whether its "GET" or whatever, its drawGraph that I am
>  > calling.  In the same way as when I call www.google.com/analytics I am
>  > calling analytics not "GET".  This is one of the things I like about
>  > REST in that it explicitly encodes the method within the URI making it
>  > simpler to read directly in the code (as opposed to in tools as with
>  > WS, which I also like), at no stage ever when I'm using REST things am
>  > I thinking "GET", I'm thinking about what the URI describes.
>
>  No Steve, REST doesn't encode the method within the URI.  With all due
>  respect, that statement shows me that you don't yet understand it.

Quite clearly, because I thought that the major idea was that the URI
was in itself documentation of the action.  Okay so drawGraph should
possibly be just "Graph" and viewing Graph as a resource, but what is
wrong from a REST perspective with a resource of
http://somewhere.com/maths/graph?x=mypoints&y=mypoints ?

GET will be idempotent and is considering graph to be a complex resource.

If you are saying that REST isn't that simple then I'm suprised.  I
was sure that choosing the right URI name was a key part of REST.

Yup not getting it....

>
>  REST is an architectural style.  It has constraints that you have to
>  follow in order to realize its benefits.  One of these constraints is
>  that operations be uniform.  On the Web, that means in effect, that
>  the operation has to be an HTTP operation (or an extension therefore,
>  e.g. WebDAV).

So you are saying that it is _bad_ practice in REST to have sensibly
named URIs?  I'm really missing which bit of REST I've violated by
having a sensibly named URI, and which bit of the "web" doesn't use
URIs to split different areas of functionality (ala the google
example).

If REST doesn't consider www.google.com/analytics differently to
http://www.google.com/trends then I've definately missed something
around the lack of importance of URI design in REST.

Steve

>
>  Mark.
>                    

Reply via email to