Rob Eamon wrote: > --- In [email protected] > <mailto:service-orientated-architecture%40yahoogroups.com>, Gregg > Wonderly <[EMAIL PROTECTED]> wrote: > > > > A service confines the workflow to the operations it supports. > > Of course. But it doesn't define the workflow. > > > Hypermedia, returned by restful services provide a strong > > indication of work flow they desire to be used. > > Traversal of resource relationships wouldn't seem to me to be > a "workflow." Perhaps we need to define what we mean by workflow to > give this thread a better defined context?
Workflow, to me, means the set of available steps that the user needs to perform to complete a task. > > The Back button on a web browser is one way that this > > workflow is circumvented. Another is litteral typing of URIs. > > I'm still not certain I'm on board with users accessing service URIs > directly. A web browser requires the user to type URIs, or something that eventually ends up in a URI. Google for example needs to know what you want to search for. There are other things that you type such as counts of things to order, addresses, zipcodes, names of things etc. So we are "typing" in URIs in some form. The question is whether that results in the formation of a human readable and understandable URI structure that a user can manipulate and craft directly. > > I am talking specifically here about restful services and > > hypermedia returned as the result of interacting with such a > > restful service. That hypermedia is supposed to "direct" the > > workflow by providing the appropriate next "actions" to > > take by using the contained hypermedia. > > I'm not sure I agree. It doesn't specify the next "action" at all. It > simply returns the child resources when asked. The child resources have/are hypermedia that restrict and designate how the user will continue to use the service. The hypermedia provides the actions that I am referring to, which limit/control/direct the work flow that the user can experience while using the service. > > Thus, the client is confined in the choices it can "automatically" > > support, except for the two mentioned above, back, or an explicitly > > typed URI that goes to a completely different service. > > Can you elaborate on "automatically" support? Are you saying the > client is driven by a workflow as defined by a service? That the > client determines the workflow by querying service(s) and not > defining the workflow for itself? A web browser is the most common form of client. When using a service, the user is confined to the choices they have based on the "action" that the returned hypermedia provides, and their bookmarks and the back button, and typing uris. Perhaps there are some other "use another service" mechanisms such as the google/yahoo search bars etc. But, I'm talking specifically about the choices a user has when using the resources returned by a particular www server in their web browser (for now). That service designates the prospect work flows the user can experience based on what's on the page. > > I don't think I am saying that a client is a service. I'm saying > > that a client using a restful service is confined by the hypermedia > > that it receives from that service. > > Right. The resource model is the interface. I'm not sure that this > approach is any more constraining than other interface styles. No, it's not, and that's not the point I am making. The point is that if a user can't type in URIs to redirect their work flow, then they are constrained. > > This limits the choices of workflow and is why I think that saying > > URIs should be non-interpretable by humans is not a useful > > argument. > > Again, I'm not really on board with users typing in URIs of services > to do their work. > > > Workflows that are the most productive is what we try to > > achieve. Practically though, we still can make arbitrary decisions > > about what the next "task" to perform might be. > > Which is the purview of the client completely, IMO. The services > don't direct which workflow task is next. hypermedia service do when interacting with clients like a web browser, which is the predominate web client in user today. > > Saying that a restful service's returned hypermedia is the only way > > to complete and order a work flow, for me, is a bit of a stretch. > > I must've missed who was making a case for that or where it was made. You are saying the user shouldn't type URIs. I'm showing ways that not typing URIs restricts what the user does next, and suggesting that typing URIs is a fine way to let the user do what they need to do. The original post, saying that URIs should be opaque, is what I'm arguing against. To me, that's a great way to restrict what a user can do, and it leads to exploitable services (in dangerous ways) because people start thinking that security is obscurity and hoping that noone will ever send them a malformed or incorrect URI. > > Sure there are some things that need to happen in order. But, > > there are always some things that don't need to happen "here". > > Allowing users the ability to make those decisions > > and to enter URIs to access a particular resource explicitly > > improves their productivity in many cases. > > That a client program would make a user key in a URI seems really odd > to me. The client program needs to provide the necessary flexibility. > If that means traversing a resource model of a service under the > covers, then it would do so. But asking a user to key in a URI? > That's seems really, really un-user-friendly to me. Just today, like everyday, I popped up the address bar that I have embedded in my windows task bar and typed "www.goo" and windows suggested www.google.com, I pressed down arrow and hit return and got to the resource I wanted, without having to wait for my browser to open, navigate to a bookmark, or go somewhere in the UI to get to google with a shortcut that required no typing. It was faster to type the URI... Gregg Wonderly
