Flex with REST Same Name Parameters, and SSL

Have a plane to catch, so figured if I blog when I have no time, I’d be brief for once in my life. Ready? Go.

Currently in Cali, awaiting for my flight to board back hom to ATL. Cali is 20 degrees colder than ATL; lame. 72 F (22 C) back to 91 F (32 C) will be a welcome change. I was here on-site with a client doing some consulting for my current contracting client. Confused yet? Don’t be, it’s fun. Figured I’d document the Flex lessons I learned while in the trenches the past 2 weeks.

First up, what do you do when a server-side developer gives you a REST API that has support for multiple parameters with each one have the same name? HTTPService won’t work as you think. HTTPService in a nutshell does a POST to some URL that supports parameters being sent to it in URL encoded variables. So, this:

var o = {};
o.name = “value”;
o.cheese = “muffin”;
o.skillz = “mad”;

becomes:

http://www.cow.com/some.php?name=value&cheese=muffin&skillz=mad

HTTPService has 2 ways to give it stuff; either set it’s request property before sending or pass it in the send function. However, if a WebSevice accepts this:

param=val1&param=foo&param=bar

Well… you’re kind of screwed. There is only 1 param…

var o = {};
o.param = “uno”;
o.param = “dos”; // overwrites uno
o.param = “tres”; // overwrites dos… all are same param variable

I tried my best to hack the IMessage object that’s associated with an HTTPService AsyncToken (mx.messaging.messages.HTTPServiceMessage I think), but no go. What to do? Uber l33t h@x of course!

1. At beginning of Cairngorm Delegate, store service URL property in member variable.
2. append your parameters manually the the server.url
3. var token = service.send();
4. in result / fault handles, set the service.url back to what it was

Works. Potential problem? If someone ELSE attempts to use that service, it’ll have that URL stored with it, with the URL encoded variables included. If your HTTPService is only ever used once, you’re good to go.

Second, SSL. SSL is not hard. I remember keeping that Ted Patrick SSL Flash / Flex entry bookmarked for the day a client would require Flash / Flex & SSL. I remember reading horror stories.

Those didn’t happen to me, though. I think in hindsight, every one’s problem was SWF security sandbox problems and NOT SSL problems. I remember reading about IE caching things, but either way, the ONLY thing that didn’t work was IE 7 on Vista because our security cert didn’t match up 100% with the real URL (we’re testing,hehe). Mac with Safari & Firefox, and PC XP with IE 6, IE 7, and Firefox all worked.

We’re not just talking about using HTTPS here for secure longins, we’re talking about:
– EVERY single request is HTTPS
– this includes file uploads
– the SWF is on the client’s website, but loaded from our webserver

That last part is the kicker. I learned that crossdomain.xml files have to explicitly allow ports, in this case 443. Dope!

Anyway, really rad to learn that if I ever develop widgets professionally, I can get SSL to work on said widget no matter where it is. I think the rule of embedding it with JavaScript with a relative path applies (like UFO or SWFObject); the SWF’ll think it’s loaded via HTTP, and go “Oh noes!!!”. Hardcode that mofo to https://blahblahblah.

Speaking of which, anyone know of any site like Akamai that supports SSL? Interested to hear how they handle it.

Finally, some cool links. talks about what I already know. Disagree about his points with regards to “if you don’t blog, you won’t get a good gig compared to someone who does” but the rest I do. If Expose and you raced, and you had this table as your computer screen, who wins? Finally, a video of Steve Jobs and Bill Gates getting interviewed together. Haven’t watched it myself but how can it not be cool?