Re: [ietf-types] Review of application/vnd.error+xml and application/vnd.error+json

Ben Longden <> Sun, 29 April 2012 13:06 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D35AE21F847A for <>; Sun, 29 Apr 2012 06:06:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.69
X-Spam-Status: No, score=-1.69 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_ILLEGAL_IP=1.908, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id hRHFsSOeLTdR for <>; Sun, 29 Apr 2012 06:06:21 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id A479021F84A1 for <>; Sun, 29 Apr 2012 06:06:20 -0700 (PDT)
Received: by wibhj6 with SMTP id hj6so1604790wib.13 for <>; Sun, 29 Apr 2012 06:06:19 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=XiBX11xg1rhTU7j3SSVXHjY2daModnDx683K8B57Q1o=; b=i/W7l1JccHZZpnHc5ExTgQ0FIRZ1sMhwBJi32gnUGvlkfCk5i4/baevk/QxLGX68Qh zb0xwWlfPBhbURKqTJBShgzylZtindR5teYiY7belv2Hhd5JxxDLQTzosalLAD9bn7l8 +b2U0lvBmiE4rDGGJE74aOPo7Bt7doNtqpqWQGv6hTSBRarQ4/XtB3bR8jDBeQIZpdTY t56ch8Q18VLFLl5ApTMWdyXn/dclY/VAUTyhgz62MDSMFWh+TZMvcs5hsQBwTu7GlNFz 6IxwvjIWoD9LOGuAZkmw8uRG4kl4L6uxaH7oyxnAa6Go+UWDPWshOhovL1gvLJ4aoFEJ 28Gw==
Received: by with SMTP id r27mr7589301wei.107.1335704779471; Sun, 29 Apr 2012 06:06:19 -0700 (PDT)
Received: from [] ( []) by with ESMTPS id ff9sm20665481wib.2.2012. (version=TLSv1/SSLv3 cipher=OTHER); Sun, 29 Apr 2012 06:06:18 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1257)
Content-Type: multipart/alternative; boundary="Apple-Mail=_12E56E8E-E1A7-4A96-901D-2F7462E3BF05"
From: Ben Longden <>
In-Reply-To: <>
Date: Sun, 29 Apr 2012 14:06:19 +0100
Message-Id: <>
References: <> <> <> <>
To: Jan Algermissen <>
X-Mailer: Apple Mail (2.1257)
X-Gm-Message-State: ALoCoQlEqoQAnHebWiA2fzuPjkNBRfZw7rH8+5MtgDHnRwmJfCdNxndUgQdnsQ2cw6GPYHn/RDPM
Subject: Re: [ietf-types] Review of application/vnd.error+xml and application/vnd.error+json
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Media \(MIME\) type review" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 29 Apr 2012 13:06:21 -0000

Hi Jan,

On 29 Apr 2012, at 01:29, Jan Algermissen wrote:

> E.g. instead of having some "Order does not exist error" design an 'order' resource semantic and use 404. There is no error condition that you cannot express that way, in terms of the uniform interface that HTTP provides.

Yes and in that situation (Order does not exist), 404 would be the correct response. What if you POST an order for an item, however there is a validation error that prevents the request from being processed. I'd return a 422, perhaps with a text/plain response containing a simple error message. The problem is that without any extra semantics, I cannot for example link to a document that explains what the correct parameters are (accepted values etc), or identify which field contained the error message along side the human readable error.

>> Even your example below is doing that.
> How so?
>> If you have a web api's then you *must* communicate using media types over HTTP. In the case of a web client, adopting this proposed standard means this is understood and disparate clients can understand the same message.
> The uniformity of HTTPs applies to the visibility components have in the *absence* of understanding the entity media types. A cache or monitoring intermediary can take action upon a 404, they cannot do that upon e.g. your proposed id="" attribute.

Agreed. I'm not advocating this as a replacement to the status code header. The id attribute is for carrying the specific reference to an error log entry on the server. This could be a URL (and perhaps should be a link with a defined rel in the spec, since out of bands information would be required to do anything with it!), but could be a database id with more specific information.

>> If I just use text/plain then I run into problems when I want to represent anything other than just the message (i.e, the id), and then have a requirement for a media type that can represent it.
> Hmm, but it is exactly the error-id that I am arguing against :-)

Does that still hold true now that I have explained how I intended the id to be used? Perhaps changing this to a link with rel='service' ( would make more sense.