Hey All; I am attaching my comments in the document (may be easier to track this way). Some other thoughts inline: On 3/14/10 8:33 PM, Roman Lapacz wrote:
Hi Aaron,
Aaron Brown wrote:
This looks good in general.
Some comments:
1. Instead of having "clienterror" and "servererror" as top-level 'things':
error/client error/server
The question is how much we want to follow HTTP status codes standard. The initial proposal tries to be very close to it. On the other hand more hierarchical approach may be more handy for us.
We need to balance expressiveness vs complexity I think. I don't have a strong opinion, but if we make things too verbose there becomes a question on how developers will use (or expand) what is available. if there is an error/client subdivision we may fall into the trap we had before (error/client/ls, error/client/ma).
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).
'badrequest' derives directly from existing HTTP status codes. I have included them but I'm not sure we need them. In the proposal pS result codes start from x30 (x31, x32, x33, ...).
Yes, lets try to think of the specific errors - I want to avoid making a general available because laziness will always win (e.g. a new service may just encode everything as a 'bad request' instead of specific errors that may or may not exist).
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/
hmm, we could say that all (or most of) client errors could be under 'badrequest' :)
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.
agree
See previous two responses, but aaron makes a good point on 'on demand parsing'.
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).
Right and that is why I included result code numbers as possible alternative.
I would say its immaterial - but a public conversion system is a good idea too (or use of the 'datum'/'parameters' to convey more than just a number). Thanks; -jason
Cheers, Roman
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