Comments on: Hypermedia and REST http://www.subbu.org/blog/2007/12/hypermedia-and-rest Wed, 08 Feb 2012 05:16:45 +0000 hourly 1 http://wordpress.org/?v=3.3.1 By: The Hypertext Constraint at Analysis from the Bottom Up http://www.subbu.org/blog/2007/12/hypermedia-and-rest/comment-page-1#comment-2074 The Hypertext Constraint at Analysis from the Bottom Up Fri, 05 Sep 2008 22:41:59 +0000 http://wp.subbu.org/2007/12/hypermedia-and-rest/#comment-2074 [...] Subbu Allamaraju on Hypermedia and REST Social Bookmarks: [...] [...] Subbu Allamaraju on Hypermedia and REST Social Bookmarks: [...]

]]> By: Subbu Allamaraju http://www.subbu.org/blog/2007/12/hypermedia-and-rest/comment-page-1#comment-198 Subbu Allamaraju Thu, 10 Jan 2008 12:09:02 +0000 http://wp.subbu.org/2007/12/hypermedia-and-rest/#comment-198 Hi John, Thanks for your comments. >> Are you making the point that because two servers are involved the ordering/interactions between the >> two is no longer RESTful? Or just that such a thing couldn't be done with "only" a universal client? No - the two servers can still be RESTful. In your example, the two servers are provide two distinct services - one to retrieve product data, and the other to manage tasks. The client agent knows about the semantics of how to create a useful service out of these two. Neither server is providing the hypermedia about how to do this integration. That knowledge is built in to your smart agent. That's my point. Subbu Hi John,

Thanks for your comments.

>> Are you making the point that because two servers are involved the ordering/interactions between the
>> two is no longer RESTful? Or just that such a thing couldn’t be done with “only” a universal client?

No – the two servers can still be RESTful. In your example, the two servers are provide two distinct services – one to retrieve product data, and the other to manage tasks. The client agent knows about the semantics of how to create a useful service out of these two. Neither server is providing the hypermedia about how to do this integration. That knowledge is built in to your smart agent. That’s my point.

Subbu

]]> By: John D. Heintz http://www.subbu.org/blog/2007/12/hypermedia-and-rest/comment-page-1#comment-197 John D. Heintz Tue, 08 Jan 2008 16:27:10 +0000 http://wp.subbu.org/2007/12/hypermedia-and-rest/#comment-197 Subbu, I agree with everything you said until the last paragraph where I have some questions. There are several ideas in that paragraph: * "universal client" * single vs multiple servers * ordering constraints from a server I suggest we are talking about a universal, but opportunistic, client. If the client has built-in support for OpenSearch, MyShoppingMediaType, or something else then it is smarter wrt media types, but still conforming to RESTful constraints. As a set of example systems: 1) My personal daily task server (allows create/close of tasks) 2) Several public shopping sites (amazon, shop.com) 3) A client agent that talks application/taskserver and application/shopping I want my shopping agent to watch a few sites for when the price of automated espresso machines drops below $400. When that happens create a new task for me on my task manager to check out the site with a link. The client is responsible for one key decision: when to create a new "task". It makes that decision after interpreting responses from the shopping servers (each with their own ordering/interaction paths for the searching). Are you making the point that because two servers are involved the ordering/interactions between the two is no longer RESTful? Or just that such a thing couldn't be done with "only" a universal client? What I'm trying to get at is more knowledge of these two things: 1) the form of my two example media types 2) the coding function of my opportunistic client I think those are the RESTful (mantaining the benefits of REST) replacement for an API defined by some IDL. Thanks! John Subbu,

I agree with everything you said until the last paragraph where I have some questions.

There are several ideas in that paragraph:
* “universal client”
* single vs multiple servers
* ordering constraints from a server

I suggest we are talking about a universal, but opportunistic, client. If the client has built-in support for OpenSearch, MyShoppingMediaType, or something else then it is smarter wrt media types, but still conforming to RESTful constraints.

As a set of example systems:
1) My personal daily task server (allows create/close of tasks)
2) Several public shopping sites (amazon, shop.com)
3) A client agent that talks application/taskserver and application/shopping

I want my shopping agent to watch a few sites for when the price of automated espresso machines drops below $400. When that happens create a new task for me on my task manager to check out the site with a link.

The client is responsible for one key decision: when to create a new “task”.

It makes that decision after interpreting responses from the shopping servers (each with their own ordering/interaction paths for the searching).

Are you making the point that because two servers are involved the ordering/interactions between the two is no longer RESTful? Or just that such a thing couldn’t be done with “only” a universal client?

What I’m trying to get at is more knowledge of these two things:
1) the form of my two example media types
2) the coding function of my opportunistic client

I think those are the RESTful (mantaining the benefits of REST) replacement for an API defined by some IDL.

Thanks!
John

]]> By: Jean-Jacques Dubray http://www.subbu.org/blog/2007/12/hypermedia-and-rest/comment-page-1#comment-196 Jean-Jacques Dubray Mon, 07 Jan 2008 23:04:41 +0000 http://wp.subbu.org/2007/12/hypermedia-and-rest/#comment-196 Subbu: are we roughly saying the same thing? at least there is nothing I can see here that I can disagree with. JJ- Subbu:

are we roughly saying the same thing? at least there is nothing I can see here that I can disagree with.

JJ-

]]>