Yes, makes sense :-) --jason
On Apr 4, 2010, at 6:43 PM, Mike Rheinheimer wrote: > Hi Jason, > > In my opinion, there are no "best practices", only "practices". :) > But seriously, the patterns used by a particular server-client REST > model will be geared toward the needs of the application or industry > in which it's employed. > > I think the lack of examples is partly intentional, in that we don't > want to influence JAX-RS application developers in a way that does not > necessarily make sense for them. However, your request is a good one. > I personally learn best by examples. If we would have ExampleError1, > ExampleError2, for possible suggested patterns, that might be useful. > Probably better to have too many examples than to deprive the > community. We'll have to fill out that Wink module better as we go. > > As for your particular request, the only specific, concrete advice I > would give you is to make proper use of the HTTP response codes. You > would, as you suggest, want to make a top-level response object, mark > it with 500 (internal server error, or whatever is appropriate for the > error being reported), and send back data that is in a format known to > the client, so it can parse it and do with it what is most useful for > your application. The client then can use the HTTP response code to > determine high-level flow (ProcessResponse vs. ProcessError, or again > whatever is appropriate for the HTTP response code), then you don't > have to parse or inspect the response entity to know what kind of > response you're dealing with. > > Make sense? > > mike > > > > > On Sun, Apr 4, 2010 at 7:35 PM, Jason Dillon <[email protected]> wrote: >> I'm trying to implement a fairly generic way to handle errors when then >> occur on the server-side, and then have a uniform way to display some-sort >> of context on the client. Is there any best practices that you folks know >> of in relation? >> >> All I can think of is that I have to create a top-level response object, >> which can contain error information or the real entity/payload that I care >> about. Or perhaps I can just have an error entity that only gets pushed >> back when an error occurs and have the client check for it before it tries >> to pull out the desired entity? Something like that... I dunno, so if you >> guys know of a better way to handle this I would be very helpful. >> >> Would have liked to see some examples of this in the distribution too. IMO, >> the current examples don't provide enough client <-> server details... lots >> of atom/rss-ish stuff, which I personally don't care about atm. >> >> Overall, I'm trying to get enough insight so that I can write an enunciate >> module to generate a java client to interact with server resources... as the >> client-code to request muck is highly boilerplate-ish. >> >> Any insight would be very helpful... and some richer wink-examples/** would >> be even better, but I'd settle for either ;-) >> >> --jason
