Jan,

I've had some success using HTTP's own CRLF delimeter as this
partition; that is to say, leaving the entity-body "8-bit clean" for
native representations in various formats and confining the meta-model
(links, categories, attributes) to the HTTP headers.

See OCCI core spec and HTTP interface at occi-wg.org where I'm also
defining an XHTML rendering for a consolidated human & programmable
web interface (semweb w microformats/RDFa etc).

Sent from my iPhone

On 04/11/2009, at 9:17, Jan Algermissen <algermissen1971@...> wrote:

>
> On Nov 4, 2009, at 3:20 AM, mike amundsen wrote:
>
>> Jan:
>>
>> As a quick follow-up on the notion of the "getting away from..."
>> issue:
>>
>> Since HTTP is a testable spec, and REST is most commonly discussed in
>> regards to HTTP, it is a short leap to consider REST-fulness to also
>> be testable; to expect there to be a "right way" to implement REST
>> over HTTP just as there is a correct way to implement the HTTP
>> application protocol.
>
> But my question is related to resource design and hypermedia design,
> not
> about how to implement HTTP.
>
> If we view linking to be part of the resource design and hypermedia
> to just be a means of serializing resource state and resource
> relationships (linking) than my question is really only about
> resource design.
>
> So, IOW, I am looking for principles that apply to the partitioning
> of the application data (resource model) and to the design of the
> relationships between the application data partitions.
>
> Probably it makes sense to ask if the application data partitioning
> may extend to the client? Is it 'valid' to put application data on
> the client that is not also maintained on the server? I think that
> is likely to be the essence of the original question.
>
> Jan
>
>
>
>> But this is not a reasonable goal. In fact, it
>> can be a hurdle to building workable applications using the style.
>>
>> mca
>> http://amundsen.com/blog/
>>
>>
>>
>>
>> On Mon, Nov 2, 2009 at 18:51, Jan Algermissen
>> <algermissen1971@...> wrote:
>>>
>>> On Nov 3, 2009, at 12:13 AM, mike amundsen wrote:
>>>
>>>> Jan:
>>>>
>>>> <snip>
>>>> I am trying to get away from the "you could do this and you could
>>>> do
>>>> that but you also could do it that way" kinds of answers to
>>>> practical
>>>> REST design questions.
>>>> </snip>
>>>>
>>>> Why do you want to get away from this?
>>>
>>> Because it does not exactly sell good if you cannot back up advice
>>> you give
>>> by principles. One of the things I admire about the Software
>>> Architecture
>>> notion laid out by Perry/Wolf, Garlan/Shaw and Roy [1] is that it
>>> creates a
>>> foundation for backing up architectural design decisions by
>>> principles. And
>>> I just get this feeling of hand waving when it comes to answering
>>> questions
>>> about 'how do I do X'. I don't mind that there are many solutions
>>> (otherwise
>>> there would not be any room for design) but (at least) I often
>>> cannot
>>> articulate a clear reasoning why and when to prefer one over the
>>> other.
>>>
>>> Take the example problem I posted. What is better for
>>> order-rejection-with-suggested-modification? To send 409 and e.g. a
>>> UBL-like
>>> order-response document (like you would in the non computerized
>>> business
>>> world) or to create an order resource anyhow, set the status to
>>> pending and
>>> then let the client update the order until it can be accepted?
>>>
>>> (I had a hunch that the latter is better than the former because it
>>> maintains application data on the server only)
>>>
>>> Likewise, several return codes have been suggested (409, 422 for
>>> example).
>>> It makes no sense to have different returns codes specified when a
>>> group
>>> like this one cannot provide a spot-on 'yeah, it is that one and
>>> only that
>>> one' response.
>>>
>>> And even if there is a single best answer - how do you get
>>> interoperability
>>> if it is so easy for different people to have different opinions
>>> about it?
>>>
>>> Jan
>>>
>>>
>>> [1] Excuses for the names missing here
>>>
>>>
>>>
>>>>
>>>> mca
>>>> http://amundsen.com/blog/
>>>>
>>>>
>>>>
>>>>
>>>> On Mon, Nov 2, 2009 at 17:09, Jan Algermissen <algermissen1971@...
>>>>>
>>>> wrote:
>>>>>
>>>>> On Nov 2, 2009, at 10:52 PM, Nick Gall wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>> On Mon, Nov 2, 2009 at 4:16 PM, Jan Algermissen <algermissen1971@...
>>>>>>>
>>>>>>> wrote:
>>>>>>
>>>>>>> My hunch is that in a RESTful system
>>>>>>>
>>>>>>> a) all application state (aka session state) is on the client
>>>>>>> b) all application data resides on the server (as resource
>>>>>>> state)
>>>>>>>
>>>>>>> The question that drives me is what the significance of resource
>>>>>>
>>>>>> state
>>>>>>>
>>>>>>> is (what is its meaning/purpose in a given design? What are the
>>>>>>
>>>>>> design
>>>>>>>
>>>>>>> conditions that lead to the creation of new resource state?
>>>>>>> Etc.)
>>>>>>
>>>>>> I am
>>>>>>>
>>>>>>> trying to get away from the "you could do this and you could do
>>>>>>> that
>>>>>>> but you also could do it that way" kinds of answers to practical
>>>>>>
>>>>>> REST
>>>>>>>
>>>>>>> design questions.
>>>>>>
>>>>>> I think I see what you are driving at with your distinction
>>>>>> between
>>>>>> session state vs resource state, but I don't think the
>>>>>> distinction
>>>>>> is so clean in REST. Here's a relevant passage from Roy's thesis
>>>>>> (5.3.3):
>>>>>>
>>>>>> The application state is controlled and stored by the user agent
>>>>>> and
>>>>>> can be composed of representations from multiple servers. In
>>>>>> addition to freeing the server from the scalability problems of
>>>>>> storing state, this allows the user to directly manipulate the
>>>>>> state
>>>>>> (e.g., a Web browser's history), anticipate changes to that state
>>>>>> (e.g., link maps and prefetching of representations), and jump
>>>>>> from
>>>>>> one application to another (e.g., bookmarks and URI-entry
>>>>>> dialogs).
>>>>>> [emphasis added]
>>>>>>
>>>>>> So at least a copy of the resource state (in the form or a
>>>>>> representation of that resource) is intended to be stored and
>>>>>> manipulated on the client side. For example, I believe this 5.3.3
>>>>>> paragraph endorses the following scenario:
>>>>>> • client receives a representation of the works of art in a
>>>>>> museum
>>>>>> exhibit as list of art works (name of work, name of artist)
>>>>>> from a
>>>>>> museum service on some museum server
>>>>>> • the client extracts the name of an artist (a string) from
>>>>>> the
>>>>>> list and submits it to Wikipedia on a different set of servers
>>>>>> • It takes the representation from Wikipedia and formats it
>>>>>> into a
>>>>>> popup for the user's UI visualization of the museum exhibit
>>>>>> In this scenario the client "jumps from one application (museum
>>>>>> service) to another (Wikipedia)", submitting representation data
>>>>>> it
>>>>>> received from the first service to the second service. Your
>>>>>> description above seems to prohibit such a scenario ("to continue
>>>>>> its interaction with the service on another machine, it would not
>>>>>> only need to take the appropriate URIs with it ... but also other
>>>>>> data elements").
>>>>>>
>>>>>
>>>>> But in your scenario, the client could allways, just be use of
>>>>> the one
>>>>> initial URI, pick up the interaction. And this is (IMHO) exactly
>>>>> the
>>>>> significance of storing the application data as resource state -
>>>>> so
>>>>> that the client can pick it up again. If the data was not stored
>>>>> in
>>>>> the server it would have to be stored on the client and the
>>>>> ability
>>>>> would be lost to pick up the conversation just on the basis of
>>>>> the URI.
>>>>>
>>>>> Jan
>>>>>
>>>>>
>>>>>
>>>>>> It appears that REST endorses the use of "application data"
>>>>>> stored
>>>>>> on the client, at least in the case where such data was at some
>>>>>> point in the past received by the client as part of a
>>>>>> representation
>>>>>> of a server-based resource.
>>>>>>
>>>>>> -- Nick
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>> --------------------------------------
>>>>> Jan Algermissen
>>>>>
>>>>> Mail: algermissen@...
>>>>> Blog: http://algermissen.blogspot.com/
>>>>> Home: http://www.jalgermissen.com
>>>>> --------------------------------------
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> ------------------------------------
>>>>>
>>>>> Yahoo! Groups Links
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>> ------------------------------------
>>>>
>>>> Yahoo! Groups Links
>>>>
>>>>
>>>>
>>>
>>> --------------------------------------
>>> Jan Algermissen
>>>
>>> Mail: algermissen@...
>>> Blog: http://algermissen.blogspot.com/
>>> Home: http://www.jalgermissen.com
>>> --------------------------------------
>>>
>>>
>>>
>>>
>>
>>
>> ------------------------------------
>>
>> Yahoo! Groups Links
>>
>>
>>
>
> --------------------------------------
> Jan Algermissen
>
> Mail: algermissen@...
> Blog: http://algermissen.blogspot.com/
> Home: http://www.jalgermissen.com
> --------------------------------------
>
>
>
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>