- Web
- Desktop
- Mobile/Tablet
- E-Mail report delivery
- The next big thing....
You can potentially solve the problem by using HTML 5 with JavaScript to deliver to all platforms. However, this may lack the native feel you might want your application to have. This isn't really the point of the post, my main point is one considering the architecture of server side components. Given that it is likely that we will want to deliver content to multiple systems over time, my goal would be to make the client as thin as possible and have the majority of the business logic on the server side. There are exceptions to this and it does depend how rich you want to make your client side solution.
REST is rapidly becoming a natural choice for the situation where you want to deliver content to multiple clients. Flex is in some circles considered a legacy technology, and in others a lot of people have bet their business on it. The issue with Flex and the compatibility with REST is it has only two modes of operation: Success and Failure. It is possible to dig further into the failure to find the exact HTTP status code. The problem is on failure you can't access the body of the message, so if you're sending a reason for the failure back to the client there is no way to capture this in Flex. The problem is discussed briefly here. If you have to start wrapping everything in success to get at the underlying error, you defeat one of the purposes in having REST in the first place. Another forum post on Adobe informs us that this is a browser/plugin issue, as the Flash player cannot actually read the body of the response.
Given this constraint can Flex ever be considered a REST compatible client? Does it have a place in a world where the expectation is many thin clients for content delivery?
That is quite an amazing limitation! Although I don't think that the inability to access the HTTP response body technically limits a client's RESTfulness. It sounds as though Flex supports the full HTTP "grammar", just not the ability to access the (optional) response body for requests that return a status code outside the 2xx range.
ReplyDeleteSections 5.1.2-5.1.7 of Fielding's thesis (http://www.ics.uci.edu/~fielding/pubs/dissertation/fielding_dissertation.pdf) outline the requirements of a RESTful service and are written in a completely protocol-agnostic manner... So it would be possible, for instance, to write a RESTful service over FTP, which doesn't support a response body for error return codes in the first place.
Interesting find though and, regardless of RESTfulness, it sounds like it would make user-friendly error reporting much more of a pain in the ass. I'm personally of the opinion that Flash and Flex should be sandboxed to the point where they can't make a request in the first place. Over any protocol.