Re: Role of operations?

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

Received on Thursday, 16 June 2005 10:20:18 UTC