2009/11/30 Paul Nasrat <[email protected]>:
> 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.

I'm just reading Jim Webber's REST tutorial

http://jim.webber.name/2009/11/20/8eae595a-d1d2-4f4f-87f6-f67280013176.aspx

A more condensed article is here:

http://www.infoq.com/articles/webber-rest-workflow

I'm not through it yet as it's a large deck but looking at it

POST /url/to/post/facts

Could return a HTTP 201 with a Location:

I'd really like us to write up our REST API interactions for puppet so
the flow is documented.

Paul

--

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.


Reply via email to