--- In [email protected], Gregg Wonderly <[EMAIL PROTECTED]> wrote: > > > Workflow, to me, means the set of available steps that the user > needs to perform to complete a task.
We're good so far. > 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. ... > 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. ... > A web browser is the most common form of client. I think this is where we may be at odds. Using a browser directly as a service client would effectively push the UI into the service itself. I think this is bad mojo. A browser, IMO, should never be a direct service client. Instead, the browser interacts with a client application, charged with being the presentation layer for the user. This presentation layer is not part of the service. It, not the browser, is the service client. As such, the browser user never has direct access to service URIs, unless the client app explicitly provides some mechanism to do so. There may be cases where this makes sense, but I would think in the majority of the cases the client app would provide access to capabilities via something other than URI entry. Thus, the client app, not the service(s), drives the workflow on behalf of its user. -Rob
