[Pulp-list] Action Parameters

[Mike McCune]

On 06/22/2010 05:58 AM, Bryan Kearney wrote:
> On 06/22/2010 12:16 AM, Jason L Connor wrote:
>> On Mon, 2010-06-21 at 16:29 -0700, Mike McCune wrote:
>>> On 06/21/2010 02:37 PM, Jason L Connor wrote:
>>>> Hi All,
>>>>
>>>> I've been playing around with making our API conform to the restful
>>>> practices in the 'rest-practices' branch. While hacking away, I've
>>>> noticed that we don't really have any particular convention for the
>>>> format of parameters (read: body) passed into action POST calls.
>>>>
>>>> There are a number of conventions we can adopt:
>>>>
>>>> 1. no convention: let each controller figure out the parameters it
>>>> expects and the order it expects them in.
>>>
>>> -1
>>>
>>> REST is free-flowing enough, lets not make it worse with no convention.
>>>
>>>
>>>> 2. only one parameter: the body contains only a single parameter, which
>>>> can be a list or dictionary of multiple parameters.
>>>
>>> still seems too untyped for me.  Even looking at the controller's
>>>
>>>>
>>>> 3. key word arguments: the body always contains a dictionary, of
>>>> <parameter name>:<parameter value>    pairs
>>>>
>>>
>>> clear, concise and obvious.  What isn't to love?
>>>
>>>> 4. others?
>>>>
>>>> ----
>>>>
>>>> The reason I bring this up is: The restful practices has produced some
>>>> very nice looking patterns that allow for some abstraction in the web
>>>> services layer. However, not having a convention for the way parameters
>>>> are passed into the action uris limits our ability of abstraction and
>>>> places a burden on both client and server developers by having to know
>>>> how to format parameters on a action by action basis.
>>>>
>>>> I don't have really strong feelings about this. But it seems like a nice
>>>> practice for consistency.
>>>>
>>>> Thoughts?
>>>>
>>>
>>> I vote #3.  keep it named and obvious.
>>>
>>>
>>
>> +1 for convention #3 as well. I think having the parameters named in the
>> body will also help us with debugging the calls.
>>
>>
>
> If (3) is a well formed json document then if you move to making the
> body a first clas resource it will be easy. Plus, it makes it easier for
> integration.
>
> On a related note, my suggestion would be for someone to hack in a
> non-python client with automatic marshalling (ActiveResource or RestEasy
> clients). It will help you learn how nice, or not, your API is.

good idea .. will give that a shot