Re: Role of operations?

Jan,

The code examples I show are server-side skeletons.

Cheers,



On Jun 16, 2005, at 3:20 AM, Jan Algermissen wrote:

> Mark,
>
> are you talking about server side code generation or client side?  
> IOW do you mean
>
> - to generate skeleton code for simplifying server side implementation
>
> or
>
> - to communicate to a client that once it has a reference (URI) to  
> some object
>   of class MyWebApp it can call a getEntryList method??
>
>
> Jan
>
>
> On Jun 16, 2005, at 11:55 AM, Mark Nottingham wrote:
>
>
>>
>> I'm not against this kind of design, but I also want to support  
>> doing a one-to-one mapping between resources and objects, as  
>> discussed before.
>>
>> In other words, the description should allow both of these forms  
>> of code generation:
>>
>> class MyWebApp:
>>     def postEntry(args):
>>         ...
>>     def getEntry(args):
>>         ...
>>     def getEntryList(args):
>>         ...
>>
>> and
>>
>> class EntryList(Resource):
>>     def GET(args):
>>         ...
>>     def POST(args):
>>         ...
>>     def resolveChild(name):
>>         return Entry(name)
>>
>> class Entry(Resource):
>>     def __init__(self, name):
>>         self.name = name
>>     def PUT(args):
>>         ...
>>     def GET(args):
>>         ...
>>
>> I don't think this is a big problem, just want to make sure people  
>> keep it in mind as a use case.
>>
>>
>>
>> On Jun 16, 2005, at 7:33 AM, Mark Baker wrote:
>>
>>
>>
>>>
>>> Hey David,
>>>
>>> On Wed, Jun 15, 2005 at 10:05:48PM -0700, David Orchard wrote:
>>>
>>>
>>>>
>>>> I think that MarkB is saying that specifying the input and output
>>>> parameters for GET/PUT/POST is violating the uniform operations.
>>>>
>>>>
>>>
>>> Not at all (?? where'd that come from?  RDF Forms supports exactly
>>> that! 8-).  I'm just saying that the Py* libraries aren't good
>>> examples for code generation because they hide the uniform interface
>>> with non-uniform API calls (like "searchByISBN").
>>>
>>>
>>>
>>>> I strongly disagree.  I think that one can have uniform  
>>>> operations that
>>>> are "strongly-typed".  At least one case is validation.
>>>>
>>>>
>>>
>>> Agreed, although as I've mentioned I think it's a bit of a slippery
>>> slope.  But for some applications, a short trip down that slope  
>>> will be
>>> manageable.
>>>
>>>
>>>
>>>> Another case is the ability to describe the xml documents  
>>>> returned and
>>>> which parts are hypermedia allows very interesting RESTful  
>>>> choreography.
>>>> For example, Atom specifies that a POST Entry to the "POSTEntry"  
>>>> URI
>>>> results in a document that has a URI for the "EDITEntry" interface
>>>> (which I think is GET,PUT, DELETE).  This association between  
>>>> two URIs
>>>> can only be done if somehow the URI in the POSTEntry response is  
>>>> tied to
>>>> the EDITEntry interface.  An ideal thing for a Web Description  
>>>> Language.
>>>>
>>>>
>>>
>>> Strongly agreed.  That's a forms language use case, since that  
>>> possible
>>> state transition is discovered at runtime.  That's what REST's
>>> "hypermedia as the engine of application state" constraint is all  
>>> about.
>>>
>>> Mark.
>>>
>>>
>>>
>>>
>>>
>>
>> --
>> Mark Nottingham     http://www.mnot.net/
>>
>>
>>
>>
>
> ______________________________________________________________________ 
> ______________________
> Jan Algermissen, Consultant &  
> Programmer                             http://jalgermissen.com
> Tugboat Consulting, 'Applying Web technology to enterprise  
> IT'       http://www.tugboat.de
>
>
>
>
>
>


--
Mark Nottingham     http://www.mnot.net/

Received on Saturday, 18 June 2005 20:51:37 UTC