Subject: [apps-discuss] Fwd: New Version Notification for draft-nottingham-http-problem-00.txt

From: Pedro Felix <[email-masked]>
Date: Sat, 4 Aug 2012 00:07:28 +0100

I also like Erik's idea:

1) Mandatory "error type" (described by) as a error code URI. If
dereferenced could return a generic representation of the error type. For
standard-like apis, this URI could be resolved by the standards site.

2) Optional "error instance" URI. When dereferenced always return a
representation of the error instance. This could be simply generated by a
template that receives the JSON properties (no state required on the server)
Example:

{
    "describedby": "http://example.com/probs/out-of-credit",
    "title": "You do not have enough credits.",
    "detail": "Your current balance is 30, but that costs 50.",
    "balance": 30,
    "required": 50
    "account": "http://api.example.com/account/12345"
    "error_instance": "http://example.com/probs/out-of-credit/instace?*
balance=30*&*account=12345&required=50*" (opaque URI for the client; needs
a better name)
}

When dereferecing http://example.com/probs/out-of-credit/instace?*balance=30
*&*account=12345**&required=50*, the server would return a representation
(e.g. text/html) of the error instance
(e.g. <p>Unfortunately, your current balance of 30 credits on <a
href="...">account 12345</a> is insufficient. At least 50 are
required.</p>).
Notice that the representation associated to "error_instance" contains the
exact same information present in the original JSON response, so no
sensitive information is disclosed. Is just presents it in a nice formatted
way.

Pedro

hello all.

thanks, mark, for the initiative!

On 2012-07-04 07:54 , mike amundsen wrote:

So the content at the other end of URI "z" will always be the same
content, no matter the app using this URI, or the specifics that
_caused_ the "problem", right?
FWIW, in my current usage, the href points to a record that is specific
to the immediate problem. This means it is possible that the server will
create and collect error logging information at these URIs.
I assume that possibility is not accounted for in your baseline design.

it seems to me there's value in having the ability to express both concepts:
an "error type" that indicates the type of problem encountered (and i think
mark's idea of using a URI for this is better than using a non-URI
identifier), as well as an "error instance" that indicates specific
information about the occurrence of the error in that particular case. both
could probably be optional, and for the type link i'd suggest to treat this
as an identifier only (clients should not dereference the URI, the only
meaningful operation would be to compare it to known error identifiers),
whereas the error instance would be expected to return a representation of
the specific error instance.

cheers,

dret.