On Nov 30, 2009, at 8:27 AM, Markus wrote: >>> >>> 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? > > I'm envisioning something much simpler. We presently map requests > on to > HTTP GETs; instead, we should map them onto HTTP POSTs. That means > we've got unlimited payload size in either direction, but otherwise > nothing changes.
Again, that doesn't solve the real problem - I want a Facts post to return a Catalog. How, as the client, would I tell the server that? Or do we just always return a catalog when someone posts facts? That seems a bit overkill. > -- Markus > > P.S. If you want to be real silly and slavishly adhere to the pretense > that the RPC -> HTTP mapping is valid, meaningful, and the names > line up > perfectly you could respond to the POST with a redirection header. Yeah, that wouldn't solve the two request/one request problem. -- While one person hesitates because he feels inferior, the other is busy making mistakes and becoming superior. -- Henry C. Link --------------------------------------------------------------------- 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.
