Re: Use Cases

Hi Mark,

except for HTTP and any shared MIME types, everything in a RESTful  
system is discovered at runetime. As it turns out (having just had  
that experience today, actually) developers demand more than HTTP and  
a MIME type at *design* time of any client side application. I am not  
sure from reading your response below if you consider runtime  
discoverable behaviour (e.g. response codes) or runtime discoverable  
forms to be used at design time. Do you?

IMHO, HTTP and the shared understanding of a MIME type *and* the  
intention of the client developer at design time are sufficient to  
actually implement the client side - if the design time expectations  
do not hold at runtime this will be detected at runtime. (I do not  
consider this a problem since there cannot be a design time  
constraint on the runtime in a distributed system anyhow so you  
allways need to check and expect insifficient data)

But the problem remains that whatever can be done, developers are  
likely to feel uncomfortable if they are not told at design time that  
"you have to post a purchase order to service X". So you end up  
giving them some sort of prescriptive schema (e.g. an XSD) and  
silently coupling the service implementation of POST to that  
expectation.

...admitedly, I got this feeling of security, too from the XSD...

Having said that, I think this is basically what the discussion about  
needing a description revolves around.

Jan



On Jun 7, 2006, at 3:34 PM, Mark Baker wrote:

>
> On 6/1/06, Paul Denning <pauld@mitre.org> wrote:
>>
>> http://esw.w3.org/topic/WebDescriptionUseScenarios?highlight=% 
>> 28CategoryWebDescription%29
>>
>> Other use scenarios that come to mind:
>>
>> 1.  Comparing descriptions of two API's.  For example, scuttle may
>> claim to implement some/all of the del.icio.us API.
>> 2.  Ability to mark a subset of an existing API; again, for example,
>> to show what subset of the del.icio.us API another similar service  
>> implements.
>
> Wouldn't you learn that via HTTP response codes?  e.g. 404 if a
> resource wasn't there, 501 if a method wasn't supported, etc..?
>
>> Another interesting aspect of interface description is
>> redirection.  For example, [1] will redirect to [2].
>
> Right, but again, that's information available in the HTTP response.
> If you try to describe, in a separate document, that redirection
> action then you've just duplicated information that is already
> trivially accessible to clients.  Is there some advantage to doing
> this that I'm not seeing?
>
> Mark.
>

Received on Wednesday, 7 June 2006 17:59:55 UTC