JSON Pointers in Error objects

[kolektiv]

The spec for 1.1 states that where the source object includes a JSON pointer: "This MUST point to a value in the request document that exists; if it doesn’t, the client SHOULD simply ignore the pointer.".

This seems slightly odd, as it leaves no way to indicate a value in the object which MUST exist but doesn't (for example, required attributes of a resource being created, or a required field in the wider document (perhaps a missing id or similar). Does this make sense to anyone else, or am I misinterpreting the intent of that field (i.e. to allow the client to report back a meaningful error in the document sent to the server).

[ethanresnick]

This seems slightly odd, as it leaves no way to indicate a value in the object which MUST exist but doesn't

The reason for this restriction is that the JSON pointer spec says that a pointer has to refer to a value that does, in fact, exist in the document that the pointer is for.

The current way to indicate that a value is required is to have the pointer refer to its parent object and then say in the error message that the parent object is invalid because it's missing the required child key.

All that said, this exact concern is what prompted me to propose the missing member in error objects, which (among other uses) would give the server a way to indicate in a machine-readable way that the parent object is invalid because it's missing some specific child key.

[kolektiv]

Yes, I see what you mean in terms of the current way - not ideal as you imply, as it's only human-consumable which is less than optimal. Still, it's a way forward - I'll take a look at that proposal as well!

[rpkilby]

Hm. It sounds like the RFC gives some leeway in handling unresolvable pointers.

From the RFC's evaluation section:

Implementations will evaluate each reference token against the document's contents and will raise an error condition if it fails to resolve a concrete value for any of the JSON pointer's reference tokens. For example, if an array is referenced with a non-numeric token, an error condition will be raised.

And from the error handling section:

This specification does not define how errors are handled. An application of JSON Pointer SHOULD specify the impact and handling of each type of error.

For example, some applications might stop pointer processing upon an error, while others may attempt to recover from missing values by inserting default ones.

I'd argue that it's reasonable for json-api to be unopinionated here, and state that it's up to the individual server implementations to specify what unresolvable pointers mean (e.g., a missing field). Thoughts?