[Nmc-wg] pS Result Codes - proposal

[Jason Zurawski]

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/invalidauthenticationtoken/
>>
>> 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ResultsCodes-20100303v3-jz.doc
Type: application/msword
Size: 59904 bytes
Desc: not available
Url : http://www.ogf.org/pipermail/nmc-wg/attachments/20100315/7ccff047/attachment-0001.doc