As far as I know, the limitation of using only GET / POST is from old netscape plugin api, adobe cannot make more that api gives. Plugin api does not allow passing something other that GET / POST. In our application (flex with REST) we used tunneling by using POST with custom headers, please take a look at:
X-HTTP-Method-Override 2012/4/26 Brett Adam <bpja...@gmail.com>: > Michael et. al: > > It's not just the player. There's definitely evildoing in the HTTPService > classes as well. > > A long long time ago I became very unhappy with the HTTPService class and > friends that constantly fought me at every turn. > > All I wanted was a nice, clean pathway to making RESTful calls from my Flex > apps. > > Oh, but yes. I wanted headers. I wanted PUT and DELETE. I wanted my own > content-types. I wanted things that (apparently) I should not want. > > GET's were being stripped of headers. GET requests of novel content types > were turned into POST requests. POST requests with no body were turned back > into GET requests. PUT and DELETE were turned into POST. > > Perversions abounded. > > I thought maybe it was just Flash Player in the browser that was living with > constraints. But AIR was similarly damaged. > > After much workaround effort with nasty POST "tunneling" strategies inspired > by the RoR community (?_method=GET !!!! ) I hacked my way into the bowels of > the darn HTTPService layer and cobbled a monkey patch to force URLLoader to > honor the originally requested method after all the other HTTPxxx classes had > done their worst. > > I wrote a few posts back when… > http://verveguy.blogspot.com/2008/07/truth-about-flex-httpservice.html > > I've attached a slightly trimmed down set of files that implement my > hack-around (removing unrelated stuff). I note that this solves the method > problem, but not necessarily the header issues. > > Since I trimmed them, I may have busted something compilation-wise. Sorry, > but I don't have a clean way to test this independently at the moment. > > Let me know if this makes sense. The basic thrust is to ultimately insert a > subclass of URLLoader way down deep in the call chain that puts the HTTP > method *back* to whatever was originally requested after it's been willfully > changed by the innards of Adobe's implementation. > > Yes, it would be much cleaner to fix this in the SDK. There's quite a lot of > special case logic in the SDK classes that would need to be carefully > unraveled and/or purged. Plenty of "oh, if this, then whack the method to be > GET" and stuff that frankly, I can't see any good reason for these days. I'm > *assuming* it was ancient browser limitations that led to what smells like > legacy code. > > It would be almost fun to fix this properly in the SDK now that it's more > open than before. Happy to help anyone game to take that on - with a first > request that there be strong unit tests in place before we begin. > > > > > -- Brett > > > On Apr 25, 2012, at 3:43 PM, Michael A. Labriola wrote: > >>> I most certainly will, Justin. This has been a dismaying experience to >>> find that the flagship service class has such a glaring glitch. >> >> I fear that, when looking deeper, you may find it is the Flash Player and >> not the service class that is your root cause, but I would be very happy to >> be wrong. >> >> Mike >> >> > >
