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? -- Tradition is what you resort to when you don't have the time or the money to do it right. -- Kurt Herbert Alder --------------------------------------------------------------------- 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.
