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

Jan Algermissen <jan.algermissen@nordsc.com> Sun, 29 April 2012 20:55 UTC

Return-Path: <jan.algermissen@nordsc.com>
X-Original-To: ietf-types@ietfa.amsl.com
Delivered-To: ietf-types@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDD1F21F85B5 for <ietf-types@ietfa.amsl.com>; Sun, 29 Apr 2012 13:55:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.641
X-Spam-Level:
X-Spam-Status: No, score=-3.641 tagged_above=-999 required=5 tests=[AWL=-1.392, BAYES_00=-2.599, HELO_EQ_DE=0.35]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kRq+7o6e3XZo for <ietf-types@ietfa.amsl.com>; Sun, 29 Apr 2012 13:55:27 -0700 (PDT)
Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.171]) by ietfa.amsl.com (Postfix) with ESMTP id E807321F8599 for <ietf-types@ietf.org>; Sun, 29 Apr 2012 13:55:26 -0700 (PDT)
Received: from [192.168.2.101] (p548FD838.dip.t-dialin.net [84.143.216.56]) by mrelayeu.kundenserver.de (node=mreu3) with ESMTP (Nemesis) id 0MhJrR-1SbbrB3UvZ-00MLK9; Sun, 29 Apr 2012 22:55:25 +0200
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: Jan Algermissen <jan.algermissen@nordsc.com>
In-Reply-To: <5812232F-0278-4AC4-94F6-2A50B3B4241F@nocarrier.co.uk>
Date: Sun, 29 Apr 2012 22:55:24 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <6F5BD73F-64C1-490A-B320-4527880418E3@nordsc.com>
References: <7C70AEAE-52F9-4575-BF66-E348ADDF9DAD@nocarrier.co.uk> <24D956A5-24CF-437A-A80C-DF6B5DAB87D6@nordsc.com> <F85EEF32-1D97-4BAE-AB80-9496D542C720@nocarrier.co.uk> <B141967F-E5DE-44D3-87E2-5BE04C9F47A2@nordsc.com> <5812232F-0278-4AC4-94F6-2A50B3B4241F@nocarrier.co.uk>
To: Ben Longden <ben@nocarrier.co.uk>
X-Mailer: Apple Mail (2.1084)
X-Provags-ID: V02:K0:8WPJTLoK4iKqrU0IgDZboPWN+zY2SDPx+U/0PuqY4KR RPgskWeImOGOf17n2bpw8VXeRgNv6HxqiUUAC6RPUBBJzf5Q4y 2zBxi2nLeBu2Iz7FmYnjYo2RiSUKsP23KRGPQqm+y6oeays6zc olM5LEZQbAm6gyULlrQw4ksiv0OXoGrpADoq3ut+Qzy9/ZnIex l9usjdrhe5Dg/8cPxUK+Mb4txAGIeB+Xs7wWvVOQgmgXAj1mF6 d4xsga/2sY0Pjlo196+vAzUpdfNbtFbF8YkwRqKug39GWE3qHT 22MzfoyVuSBAMUYitK+U38HRfKDUyjgXtEVqOXRZAE4CPMZeTi fdjA+6rqK4agrVk5BpmU1sdJz3eco9yVm7Ae/fl5n3zRriFyYB Cf+GEulYIlyTg==
Cc: ietf-types@ietf.org
Subject: Re: [ietf-types] Review of application/vnd.error+xml and application/vnd.error+json
X-BeenThere: ietf-types@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Media \(MIME\) type review" <ietf-types.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf-types>, <mailto:ietf-types-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf-types>
List-Post: <mailto:ietf-types@ietf.org>
List-Help: <mailto:ietf-types-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf-types>, <mailto:ietf-types-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 29 Apr 2012 20:55:28 -0000

On Apr 29, 2012, at 3:06 PM, Ben Longden wrote:

> 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.

Ah - I see. Thanks for clarifying. I really thought you meant to use id for the kind of error. Sorry for misunderstanding.


> 
>>> 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.

URL sounds best. But I'll take a look at the issue from the 'new' angle. Might not be until Tuesday though.

Again, sorry for the confusion.

Jan


> 
>>> 
>>> 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' (http://www.iana.org/assignments/link-relations/link-relations.xml) would make more sense.
> 
> Ben.
> 
> _______________________________________________
> ietf-types mailing list
> ietf-types@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf-types