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. 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.
