This question comes from a *nix sysadmin (and all-around good guy):
“Jim, do you have a way to make flex handle a richer set of HTTP status codes in a portable way? Without that, I’m hesitant to recommend it for REST deployments.”
This is certainly a reasonable concern. The fact that Adobe still has not addressed this issue after all these years seems truly odd. To get an idea of the amount of trouble this causes, go to the Flex Bug and Issue Tracker at http://bugs.adobe.com/jira/secure/QuickSearch.jspa , type “http status code” in the Quick Search box (upper right corner) and see how many results you get.
Having said that, let us now look at what to do about it. First, note that it is not really a Flex issue per se. Remember, Flex is simply a framework (or tool kit or set of libraries or whatever you like to call it) for building Flash applications, so a Flex application is nothing but a type of Flash application. Therefore, Flex applications necessarily suffer from any weaknesses in the Flash VM. And this particular issue, as I understand it, is a weakness in the Flash runtime.
Knowing where the problem lies is half the battle. Since the problem under consideration lies in the Flash Player, we know that we can’t fix it with Flex code, and so we need to work around it some other way.
[Update: James Ward points out in his comments below that, strictly speaking, this issue has its roots in the way the browsers treat their plugins, which is not always very nice. However, from the Flash/Flex developer's perspective, it makes no practical difference: We still can't fix the problem with ActionScript, and the kind of workarounds discussed here are required whether the problem is in the plugin or in the browsers' plugin API. And even it the problem is in the browsers' plugin API, the end result is a limitation in Flash.]
One approach is to catch your errors with the server-side code and output messages that can be read by any client. Depending on the server technology and the developers working with it, this can be a very easy and effective approach to the problem. With ColdFusion, for example, you can do something as simple as this:
<cftry> <!--- Do whatever processing you need to do here, such as a <cfquery> ---> <cfoutput> <result> <error> <code>0</code> </error> <!-- Define the XML output here ---> </result> </cfoutput> <cfcatch> <cfoutput> <result> <error> <code>1</code> <message>#cfcatch.Message#</message> <type>#cfcatch.Type#</type> </error> </result> </cfoutput> </cfcatch> </cftry>
You can do similar things with Alfresco web scripts, JSP, ASP, PHP, etc. This approach will handle the majority of server-side errors in a way that any UI client could work with. However, it does not cover every scenario, and it may not address the portability aspect of the question that we started with. Besides, you simply do not have this option in every situation (for example, when attaching a Flex UI to an existing application). So we need to go a bit further.
One practice I recommend is writing simple HTML forms to invoke the services. These forms are bare-bones, with no styling and very little attention given to layout; they are purely for functionality. I do this regardless of whether I am writing the server code myself or I am just building the UI to someone else’s code. (Side point: One of the many things I like about Rails is that it builds this scaffolding for you.)
These HTML forms are used in two ways. First, use them to test the server code before running it from the Flash/Flex application. If the application doesn’t work correctly this way, then you know it won’t work from your Flash GUI. Once everything appears to be working from the HTML forms, you are ready to start running the application using the Flash GUI.
Now, if you get an error that Flash is not able to handle, you have an easy way to debug it. Simply enter the same data in your HTML form that was entered in the Flash GUI, submit the form, and see what the error message is. In the vast majority of cases, this will point you to the cause of the error, and hence the solution.
It is true that this requires some extra work on the part of the Flash/Flex developer. And this is really where the answer lies: in the developer.
Every technology has limitations. I will go further, and say that every technology has serious limitations. Even if you go down to something as simple as the hammer, and you think about it a little, you will see that it has serious limitations. This does not prevent us from working with the technology. Rather, if we see a benefit in the technology, we learn to work with it in spite of its limitations.
Having worked with this particular technology since the days of Flash 4, I am very pleased with the progress that Macromedia and Adobe have made, and rarely find reason to complain. However, I do realize that some of the remaining limitations can be frustrating - especially to people who are new to Flash, and find there are things which are very simple in other technologies that are not so simple in Flash. What to do about these things? Again, it comes down to the developer.
The best solution to the HTTP status code issue, and other such issues, is to use Flash/Flex developers who have the experience and/or tenacity to make the technology work in spite of its limitations. In the hands of such people, Flash can work wonders, and the non-Flash team members do not feel particularly burdened by the fact that Flash is being used for the UI.
On the other hand, if you are building large, complex applications with inexperienced Flash developers, then your entire team is going to feel the pain. But that is the same with every technology you use in your development and deployment. If you have inexperienced DBAs, Java developers, Alfresco developers, or sysadmins, everyone suffers.
Twenty-five years ago, when I bought my first 22-oz Estwing , I found it to be unwieldy and tiring. It was much harder to swing than my old 16-oz hammer, and the guys I worked with got some laughs (and some frustration) watching me make my blunders with it. However, I had seen how effective it could be in the hand of an experienced carpenter. So, even though it caused me a lot of pain - to the point of losing a fingernail - I kept using it, and eventually found it to be indispensable. And, in the end, I was much more of an asset to the crew than I had been previously. It is a great tool.
Flash and Flex are great tools, too.