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

From: Ray Polk <[email-masked]>
Date: Fri, 8 Mar 2013 14:28:18 -0800 (PST)

I think http-problem is a good idea, and we're looking at adopting it.  A few questions: 

Has the notion of errorF ield or problemP ath been considered?  G iven 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. 

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 subP roblem field or array that contains additional problems? 

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

Regards, 

Ray

---

From: Erik Wilde <[email-masked]>
Date: Fri, 08 Mar 2013 16:45:39 -0800

hello ray.

thanks for the feedback.

On 2013-03-08 14:28 , Ray Polk wrote:
> 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:[email-masked]  -  tel:+1-510-2061079 |
            | UC Berkeley  -  School of Information (ISchool) |
            | http://dret.net/netdret http://twitter.com/dret |