Currently, KZOE provides the same error message on an invalid $ref URL, regardless of whether the problem is with the base URL (i.e. the scheme://domain/path part), the JSON Pointer fragment that follows (i.e. the #/definitions/customer part), or failure to parse the retrieve content.
Invalid Reference - Unable to resolve the reference. The value must be a valid JSON Reference (for external references) or JSON Pointer (for local references), and must resolve to an object of the expected
type.
It would be helpful to have differentiated error messages, depending on the cause. There are at least three general categories of failures like this:
Could not retrieve the resource - In this case, we would want to display an appropriate error from the filesystem (for file URLs) or from the HTTP client (for http/https URLs, including the HTTP response code, error text, etc.)
Could not parse the content - We couldn't determine the format (media type, content-type) of the retrieved content, or could not successfully parse the content.
Could not resolve the JSON Pointer fragment - We were able to retrieve and parse the content, but the JSON Pointer fragment was not valid. If possible, the error message should point out a specific node or character position in the JSON Pointer that was problematic. For example, given /foo/bar/baz/parameter, if we found foo/bar but that wasn't an object, we should say so. If we found foo/bar as an object value, but no baz property, we should say so.
Currently, KZOE provides the same error message on an invalid
$refURL, regardless of whether the problem is with the base URL (i.e. thescheme://domain/pathpart), the JSON Pointer fragment that follows (i.e. the#/definitions/customerpart), or failure to parse the retrieve content.It would be helpful to have differentiated error messages, depending on the cause. There are at least three general categories of failures like this:
/foo/bar/baz/parameter, if we foundfoo/barbut that wasn't an object, we should say so. If we foundfoo/baras an object value, but nobazproperty, we should say so.