Re: [apps-discuss] draft-nottingham-http-problem

[Ray Polk <[e-mail]>]

True; error location & multiple errors are useful for validation of the body.  Those notions might also be useful for multiple input errors of other types as well, right?

403 - we return 403 when user agents provide incorrect CSRF prevention tokens &/or access_tokens &/or don't have permission.  we're required to inform UA of the issue (otherwise return 404); if both the CSRF token & access_token are wrong, we'd like to inform on both issues in one response; possibly specifying the erroneous query param or entity value.

406 - UA might have gotten more than one header wrong; so might be good to specify which headers were wrong in order to scope the required list of valid values

409 - where multiple fields violated some kind of scope/uniqueness constraint

Multiple errors needn't be only with input (headers, query parameters, request body) either.  I could envision a request causing more than one top level error (say...406 & 409 at the same time).

So anyway, w/e was chosen for error location (errorPath / errorFragmentIdentifier / ...) might need to handle identifying header, query param, request entity field....matrix param?  ...path param?!  ...or should there be one response field per input type?  ...or...?

-----------

Could you provide an example of using an anchor / frag id?  would it just be the json/yaml/xml/... field prefixed with a hash?

-----------

Regarding "more" -- custom top level field are also allowed in the response, right?  to be ignored by clients?  (per sec 3.3)  If that's the case, is there need for the "more" section?

Regards,
Ray

----- Original Message -----
From: [e-mail]
To: [e-mail]
Cc: [e-mail]
Sent: Friday, March 8, 2013 5:45:47 PM GMT -07:00 US/Canada Mountain
Subject: Re: [apps-discuss] draft-nottingham-http-problem

hello ray.

thanks for the feedback.

On 2013-03-08 14:28 , Ray Polk wrote:
> I think http-problem is a good idea, and we're looking at adopting it.
> A few questions:
> Has the notion of errorField or problemPath been considered?  Given a
> problem, say 422, it might be useful to point out the associative array
> entry / attribute / field that was problematic.  The value could be the
> field name or jsonPath to the erroneous field.

this sounds mostly like a validation approach, where you are validating 
the request and then have a specific point where validation failed. 
while this is something that can happen, the question is whether this is 
general enough to warrant a specific field. problems can occur for many 
reasons, and validation is just one part of that.

if such a field was added, the best way to do it might be a fragment 
identifier, because the media type of the request could be anything, and 
maybe the most general way to point to something might be a fragment 
identifier.

> Other than adding additional info to "more", is there any consideration
> for multiple problems in one response?  For instance, there may be more
> than one problematic field in a request.  It would be advantageous to
> report them all at once instead of piecemeal.  Perhaps a subProblem
> field or array that contains additional problems?

again, that sounds a lot like being very validation-oriented. the idea 
is to report HTTP-level problems, not so much validation messages about 
specific fragments where the requests caused validation problems. if 
this kind of validation and reporting resulting errors is what you want 
to do, the "more" is probably the way to go.

> Has anyone written a bit of client code for this yet?

nothing generic that i am aware of, but we're using it in specific 
client code. and maybe it's a bit early for broader adoption because the 
format is still evolving. mark probably can chime in here.

cheers,

dret.

-- 
erik wilde | mailto:[e-mail]  -  tel:[phone] |
            | UC Berkeley  -  School of Information (ISchool) |
            | http://dret.net/netdret http://twitter.com/dret |