This is my opinion - take it with a grain of salt ;-} I don't believe REST services should include errors in HTTP headers. There was no problem with the HTTP - the error was generated in your code. These types of errors should be returned as part of the data payload.
In all of my SOAP code I either return an error object with error code and error message XML nodes. If there is a SOAP Fault, that is also returned as part of the XML. Looking at HTTP headers is not required. Steve --- In flexcoders@yahoogroups.com, Terry May <terry...@...> wrote: > > Hello, > > I am currently working on integrating our company's soon to be public API > with Flash/Flex. Our server side engineers have built a sensible REST based > service, after years of working with flash integration using XML-RPC I am > very happy with the API they have put together and want to try to maintain > the simplicity, Flash/Flex/AIR on the other hand, want nothing to do with > it. > > I was trying to use BlazeDS as a Proxy to get around the Browser's > retardation with status codes and headers (I am just going to assume you all > know what I mean.) but as it turns out BlazeDS doesn't do the right thing > either. So I thought I would get on the list and see what suggestions you > guys (and gals) might have. > > Here are 2 responses from our service, the first is a sucessful > registration. In Flex when I get this response it fires a proper result > event, and I get the message body just fine. it is the location header that > I don't seem to be able to get to. (using HTTPSerivce with or without > proxy) > > > POST /v1/eprize/ews01/profiles HTTP/1.1 > > User-Agent: curl/7.16.3 (powerpc-apple-darwin9.0) libcurl/7.16.3 > OpenSSL/0.9.7l zlib/1.2.3 > > Host: foo-xxxxxxxx.int.eprize.net > > Accept: */* > > Content-Length: 84 > > Content-Type: application/x-www-form-urlencoded > > > < HTTP/1.1 201 Created > < Date: Wed, 20 May 2009 14:12:39 GMT > < Server: Apache/2.2.4 (Unix) mod_perl/2.0.3 Perl/v5.8.8 > < location: http://foo-xxxxxxxx.int.eprize.net/eprize/ews01/profile/7 > < pragma: no-cache > < cache-control: no-cache > < expires: Wed, 20 May 2009 14:12:39 GMT > < content-length: 201 > < Content-Type: text/xml; charset=utf-8 > < > <?xml version="1.0" encoding="UTF-8" ?> > <result> > <profile> > <id>7</id> > <country></country> > <first_name>terry</first_name> > <locale></locale> > <state></state> > </profile> > </result> > > > The second response is a fault response. I caused the fault by trying to > register the same account information twice. This is really where the > biggest problem is, using BlazeDS I can only see the HTTP Status Code in > fault event. I really need the message body and in some cases the headers > in the fault event. I looked into the BlazeDS source and it is actually > throwing the fault exception before it can write the headers and body to the > response, frustrating. > > > POST /v1/eprize/ews01/profiles HTTP/1.1 > > User-Agent: curl/7.16.3 (powerpc-apple-darwin9.0) libcurl/7.16.3 > OpenSSL/0.9.7l zlib/1.2.3 > > Host: foo-xxxxxxxx.int.eprize.net > > Accept: */* > > Content-Length: 84 > > Content-Type: application/x-www-form-urlencoded > > > < HTTP/1.1 409 Conflict > < Date: Wed, 20 May 2009 14:15:05 GMT > < Server: Apache/2.2.4 (Unix) mod_perl/2.0.3 Perl/v5.8.8 > < pragma: no-cache > < cache-control: no-cache > < expires: Wed, 20 May 2009 14:15:05 GMT > < content-length: 113 > < Content-Type: text/xml; charset=utf-8 > < > <?xml version="1.0" encoding="UTF-8" ?> > <result> > <terminal_error>duplicate_account</terminal_error> > </result> > > > so this is my last ditch effort to figure out a solution to this before I > tell our server side engineers to make a special method for 'Broken' http > clients to always pass status of 200, and include all the http junk in the > xml.. this makes me sad, because it means some extra work on the client > side and it sure is not as elegant. Perhaps I missed something with > BlazeDS, sure would be great to have some second opions. (I have looked the > as3HTTPClient listed in the Flex cookbook, and I am not really into using it > because it seems like it would cause a customer support nightmare) > > Thanks, > Terry May > Flash Platform Software Engineer > Detroit Area Abode User Group Manager >
