On Nov 30, 2009, at 12:41 AM, Paul Nasrat wrote:
> 2009/11/30 Luke Kanies <[email protected]>:
>> On Nov 28, 2009, at 11:54 AM, Markus wrote:
>>
>>>
>>>> In our case it's not so much that we have an ivory tower but that
>>>> we
>>>> have a system implemented around GET, with no real provision for
>>>> ever
>>>> using POST. Not that it's impossible, but it'd be a one-off for
>>>> both
>>>> client and server, or it would drastically complicate the model we
>>>> use
>>>> for passing information around the network.
>>>>
>>>> Hmm, well, maybe not drastically; I suppose we could have an
>>>> argument
>>>> that causes the equivalent of a 'get' to be returned as the
>>>> result of
>>>> the original call. That's still a significant change -- would we
>>>> have
>>>> to change our 'put' to a 'post'? -- but not untenable, I think.
>>>
>>> It could be even simpler, I think.
>>>
>>> * Switch to issuing a POST everywhere that we presently issue a GET,
>>> with a fallback to GET if the POST is rejected (405) or even better
>>> based on the api version for mixed system backwards compatibility.
>>>
>>> * Switch to accepting both POST and get where we now accept only
>>> GET.
>>
>>
>> I'm comfortable with this, and I like the idea of the server being
>> agnostic about post/get.
>>
>> It only gets us halfway, though - we need a POST to return the
>> results
>> of another query entirely (i.e., the POST of the Facts should return
>> the results of a GET of a Catalog). How would we do that?
>
> It's worth thinking about what HTTP gives us here to do things like
> this. One option would be to respond to the post with a temporary
> redirect to the catalog that the client then GET's.
>
> It's probably worth thinking about how the REST API works at the HTTP
> level as well if you want to do the "scale it like any rails app".
> There are a lot of things we can do (If-Modified-Since, Etag, Expires)
> to handle both metadata and caching rules.
Yeah, there's a lot of interesting stuff we can do here, but my main
interest at this point is getting the architecture to the point where
we can actually do these interesting things, rather than starting with
them out of the gate.
--
You don't learn anything the second time you're kicked by a mule.
-- Anonymous Texan
---------------------------------------------------------------------
Luke Kanies | http://reductivelabs.com | http://madstop.com
--
You received this message because you are subscribed to the Google Groups
"Puppet Developers" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/puppet-dev?hl=en.
