An idea that's been needling in my head for a while, just want to float it out
there.  This likely has been discussed before and I've just missed the thread.


  Suppose the following

1. you have a media type that describes how to interact with other resources.

2. you have resource http://MetaA that describes how to interact with a
hyperlinked resource, http://RealA.

3.  MetaA's representation has defined a very long cache TTL (say, 3 months)

4. A user agent that GETs the representation MetaA,  caches the representation
of MetaA, and prompts User 1 to manipulate MetaA's representation to configure
integration of the user agent's overall application to representations that may
be transferred to/from RealA

5. This same user agent is leveraged by User 2 over many months to interact with
RealA given the cached MetaA.

6. If MetaA's representation changes, the User 1 is notified by the user agent
(via some undefined mechanism) to change its configuration so that User 2 can
continue to interact with RealA.

Steps 1 - 3 are "design time",  steps 4-5 are "runtime" in the traditional sense
of the term;
User 1 is a developer (or technical user)
User 2 is an automaton (i.e. client code of some sort)
Both MetaA and RealA's representations are part of the application state (aka.
its hypermedia workspace), but the origin server(s) have set different
expectations on how long they can be cached (MetaA for a long time, RealA for a
short time).


Or, if you're more concrete minded, imagine:
- You write a scraping application that caches an HTML form to a stock quote
service, which a developer then uses to generate URIs to GET a stock quote
price.   The application is smart enough to periodically GET the HTML form and
can detect changes, but would require developer intervention in some cases, such
as if the required bound form field names changed.

My question:

How is this not RESTful? (in the sense of it not being respectful of the
constraints of the style and thus sacrificing some beneficial properties like
scalability, evolvability, etc.)

My proposition:

1. If this is not RESTful, we'll have to talk.

2. If this is RESTful, we need to be really careful when we say there's no
"design time" in RESTful systems.

I think the clearer statement is that "static code generation" (e.g. client
stubs) is discouraged in properly RESTful systems, since it tends towards
sucktacular rigidity in the user agent.


Cheers
Stu

--- In rest-discuss@yahoogroups.com, Stuart Charlton <stuartcharlton@...> wrote:
>
> gah, a typo
>
> "Steps 1 - 3 are "design time", steps 4-5 are "runtime" in the traditional
> sense
> of the term;"
>
> should read
>
> "Steps 1 - 4 are "design time", steps 5-6 are "runtime" in the traditional
> sense of the term;"
>
> ________________________________
> From: Stuart Charlton <stuartcharlton@...>
> To: rest-discuss@yahoogroups.com
> Sent: Tue, February 22, 2011 10:03:47 PM
> Subject: [rest-discuss] design vs runtime in representations
>

<snip>

> My question:
>
> How is this not RESTful? (in the sense of it not being respectful of the
> constraints of the style and thus sacrificing some beneficial properties like
> scalability, evolvability, etc.)
>
> My proposition:
>
> 1. If this is not RESTful, we'll have to talk.
>
> 2. If this is RESTful, we need to be really careful when we say there's no
> "design time" in RESTful systems.
>
> I think the clearer statement is that "static code generation" (e.g. client
> stubs) is discouraged in properly RESTful systems, since it tends towards
> sucktacular rigidity in the user agent.
>
> Cheers
> Stu
>

Stu,

The amount of runtime flexibility depends on the hypermedia controls that are
available. For example, if there were no links or forms in HTML, then the
browser (or the user) would be bound to the interface specifics of every service
out there.

A hypermedia control is only partially a data construct. A control is
instantiated as the result of client processing of the data. If a client does
not (or cannot) interpret <form> as a control then you lose the runtime
flexibility that that control provides.

A developer can make up for that by interpreting the control themselves and
coding the knowledge in the client, but then as you say, they are turning a
runtime binding into a design-time binding.

HTML and it's controls are primarily designed for browsers presenting
information to humans. It has some features like <link> and rel that target
alternate, machine-driven clients but the language is not powerful enough to
provide equivalent machine controls for every human control expressible in the
language.

I believe that it is possible to build machine controls that provide much more
run time flexibility than is afforded machines by HTML. I always point to CCXML
as an example of this. I suspect, however, that the more powerful machine
controls are, the more they must target specific types of machines. I think the
whole area needs more investigation though.

In short, I don't think it's a question of RESTful vs. not RESTful. I think you
are simply noting that the degree of runtime flexibility afforded to the system
is a function of both the hypermedia format *and* the client.

Regards,

Andrew

On Wed, Feb 23, 2011 at 5:03 AM, Stuart Charlton
<stuartcharlton@...> wrote:
>
> 2. If this is RESTful, we need to be really careful when we say there's no
> "design time" in RESTful systems.
>

Do you mean RESTful applications consumed by automated clients? If so, +1

I think it's a key consideration when designing media types,
specifically their hypermedia controls, that are aimed at these sorts
of automated clients. Media types that over-provision mechanisms for
run-time dynamism may give servers false confidence in terms of what
sorts of changes they can enact.

Cheers,
Mike

Comments inline

--- On Wed, 2/23/11, Mike Kelly <mike@...> wrote:

> > 2. If this is RESTful, we need to be really careful
> when we say there's no
> > "design time" in RESTful systems.
> >
>
> Do you mean RESTful applications consumed by automated
> clients? If so, +1

Yes that's what I meant.

> I think it's a key consideration when designing media
> types,
> specifically their hypermedia controls, that are aimed at
> these sorts
> of automated clients. Media types that over-provision
> mechanisms for
> run-time dynamism may give servers false confidence in
> terms of what
> sorts of changes they can enact.

Right; the media type itself needs to provide guidance on expectations of how it
will be used.

For example, I think media types for automated consumption really should refer
to something like RFC 5829 for dealing with versioning, with a clear delineation
of elements that can/should change & be dealt with at runtime, vs. elements that
may require more lead time and thus a "successor-version" link would help some
user agents out.

Stu

Stu:

the idea of using RFC 5829 is interesting.

on a similar track, iv'e been toying w/ using the RFC 2119 words
(MUST, MAY, etc.) as a way to decorate hypermedia elements in a
"profile" that is consumable by agents. in theory (LOL) agents could
compare their own "design-time profile" (indicating what that agent
currently supports) with the "run-time profile" provided in the
response (@profile in the document, profile param in media type, Link
header, etc.).  Mismatches could be handled by the agent as "stop",
"warn", "ignore", etc.

mca
http://amundsen.com/blog/
http://twitter.com@mamund
http://mamund.com/foaf.rdf#me


#RESTFest 2010
http://rest-fest.googlecode.com




On Wed, Feb 23, 2011 at 15:59, Stuart Charlton <stuartcharlton@...> wrote:
>
> Comments inline
>
> --- On Wed, 2/23/11, Mike Kelly <mike@...> wrote:
>
>> > 2. If this is RESTful, we need to be really careful
>> when we say there's no
>> > "design time" in RESTful systems.
>> >
>>
>> Do you mean RESTful applications consumed by automated
>> clients? If so, +1
>
> Yes that's what I meant.
>
>> I think it's a key consideration when designing media
>> types,
>> specifically their hypermedia controls, that are aimed at
>> these sorts
>> of automated clients. Media types that over-provision
>> mechanisms for
>> run-time dynamism may give servers false confidence in
>> terms of what
>> sorts of changes they can enact.
>
> Right; the media type itself needs to provide guidance on expectations of how
it will be used.
>
> For example, I think media types for automated consumption really should refer
to something like RFC 5829 for dealing with versioning, with a clear delineation
of elements that can/should change & be dealt with at runtime, vs. elements that
may require more lead time and thus a "successor-version" link would help some
user agents out.
>
> Stu
>
>
>
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>
>

comments inline

--- On Wed, 2/23/11, mike amundsen <mamund@...> wrote:

> the idea of using RFC 5829 is interesting.

Yeah, I mean why not, right?   I know it was designed for content management,
but representations that include forms really could use versioning like this
too, so that rigid user agents can have time to adapt.  They could bind against
a specific version, whereas a more adaptive user agent could always bind against
latest-version.

> on a similar track, iv'e been toying w/ using the RFC 2119
> words
> (MUST, MAY, etc.) as a way to decorate hypermedia elements
> in a
> "profile" that is consumable by agents. in theory (LOL)
> agents could
> compare their own "design-time profile" (indicating what
> that agent
> currently supports) with the "run-time profile" provided in
> the
> response (@profile in the document, profile param in media
> type, Link
> header, etc.).  Mismatches could be handled by the
> agent as "stop",
> "warn", "ignore", etc.


Cool, reminds me of Telnet option negotiation:
http://www.faqs.org/rfcs/rfc1143.html

Cheers
Stu

> Cool, reminds me of Telnet option negotiation:
http://www.faqs.org/rfcs/rfc1143.html

ha! forgot about those.

thanks.

mca
http://amundsen.com/blog/
http://twitter.com@mamund
http://mamund.com/foaf.rdf#me


#RESTFest 2010
http://rest-fest.googlecode.com




On Wed, Feb 23, 2011 at 21:17, Stuart Charlton <stuartcharlton@...> wrote:
> comments inline
>
> --- On Wed, 2/23/11, mike amundsen <mamund@...> wrote:
>
>> the idea of using RFC 5829 is interesting.
>
> Yeah, I mean why not, right?   I know it was designed for content management,
but representations that include forms really could use versioning like this
too, so that rigid user agents can have time to adapt.  They could bind against
a specific version, whereas a more adaptive user agent could always bind against
latest-version.
>
>> on a similar track, iv'e been toying w/ using the RFC 2119
>> words
>> (MUST, MAY, etc.) as a way to decorate hypermedia elements
>> in a
>> "profile" that is consumable by agents. in theory (LOL)
>> agents could
>> compare their own "design-time profile" (indicating what
>> that agent
>> currently supports) with the "run-time profile" provided in
>> the
>> response (@profile in the document, profile param in media
>> type, Link
>> header, etc.).  Mismatches could be handled by the
>> agent as "stop",
>> "warn", "ignore", etc.
>
>
> Cool, reminds me of Telnet option negotiation:
http://www.faqs.org/rfcs/rfc1143.html
>
> Cheers
> Stu
>
>
>
>
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>
>

comments inline

--- On Wed, 2/23/11, wahbedahbe <andrew.wahbe@...> wrote:


> The amount of runtime flexibility depends on the hypermedia controls that are
available. For example, if there
> were no links or forms in HTML, then the browser (or the user) would be bound
to the interface specifics of
> every service out there.

Yes, I agree.

> A developer can make up for that by interpreting the control themselves and
coding the knowledge in the
> client, but then as you say, they are turning a runtime binding into a
design-time binding.

Well, the question is, should domain-specific data be tightly coupled to a
generic media type or not.

Let's assume a generic media type, like a <form>.   A representation may have an
<input name="quoteSymbol"> that a user agent could bind against to its
application.   However, we're always going to have disagreement in data: 
between representations from different origin servers, between the
representation and the user agent's application - not everyone will use the same
data definitions, symbols, etc.   The best we can hope for is standardized bits
& pieces of highly common data, perhaps some highly common industry consortium
data (e.g. ISO 20022 or EDI), and a straightforward way to handle the rest of
the differences.

This straightforward way of handling differences tends to imply a combination
of:
1. an explicit data model in the media type,
2. data transformation advice (e.g. linking to an XSLT),
3. deeper semantic description from another representation (e.g. SKOS, OWL,
etc.),
4. or a user has to manipulate the representation to conform to client
application expectations.

The latter case we might call a mashup developer today.

> I believe that it is possible to build machine controls that provide much more
run time flexibility than is
> afforded machines by HTML. I always point to CCXML as an example of this. I
suspect, however, that the more
> powerful machine controls are, the more they must target specific types of
machines. I think the whole area
> needs more investigation though.

SCXML (and CCXML by extension), has an interesting take on this and may have a
practical solution for future media types, though I wish SCXML had richer
support for HTTP interactions.  It partly gets around the data problem by
describing an explicit data model and mappings to ECMAscript & XPath.

But even still, if we had an application that was concerned with integration, we
would need some kind of configuration in the user agent to bridge the gap
between the data (and events / state transitions!) in the representation and my
internal application data.    This configuration would occur AFTER we had
retrieved the SCXML document.   We could build some clever semantic extensions
to ease this burden, but practically speaking, it can only go so far.

This is why I brought up the need for a design time / run time separation
between retrieving the representation describing an unsafe operation (e.g. a
stock quote order form), or a process (e.g. an SCXML to order stocks), and the
actual endpoints that will be repeatedly invoked at runtime (e.g. a live stock
quote).

We can't get completely away from the divergence of semantics in data & actions,
though I bet we could close the gap from today's situation by quite a lot.

Cheers
Stu