- 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?
