Re: Role of operations?

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/

Received on Thursday, 16 June 2005 09:55:08 UTC