This looks good in general. Some comments: 1. Instead of having "clienterror" and "servererror" as top-level 'things': error/client error/server 2. badrequest seems almost a catch-all. (e.g. eventtypenotallowed is a form of badrequest, etc). If it's for a more specific error, it'd probably be good to define that error. In general, it'd probably be good to detail when some of these errors get used (e.g. use badrequest unless one of the more specific errors is applicable). 3. It might make sense to make it a bit more hierarchical (though this may be overkill), e.g.: http://perfsonar.net/status/error/client/badrequest/eventtypenotallowed/ This would make it easier for clients to understand new error types. e.g. http://perfsonar.net/status/error/client/unauthorized/invalidauthenticationt... The client wouldn't need to understand anything below "unauthorized", to display a "authorization denied" error, but it could provide more information if it understood. 4. I'm not a big fan of the result codes as having some text in the url makes it notedly more readable (not that users would read the event types, but for developers). Cheers, Aaron On Mar 3, 2010, at 9:06 AM, Roman Lapacz wrote:
As promised Slawek and I have prepared a doc describing new result codes. Comments and updates are welcome.
Cheers, Roman
_______________________________________________ Nmc-wg mailing list Nmc-wg@ogf.org http://www.ogf.org/mailman/listinfo/nmc-wg
Internet2 Spring Member Meeting April 26-28, 2010 - Arlington, Virginia http://events.internet2.edu/2010/spring-mm/