                                                                                                                                                                                                                                                                
Received-SPF: pass (google.com: domain of Arlo.Bels...@microsoft.com designates 216.32.180.12 as permitted sender) client-ip=216.32.180.12;
Received-SPF: pass (mail171-va3: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Arlo.Bels...@microsoft.com; helo=TK5EX14MLTC104.redmond.corp.microsoft.com ;icrosoft.com ;
From: Arlo Belshee <Arlo.Bels...@microsoft.com>
To: "api-craft@googlegroups.com" <api-craft@googlegroups.com>
Subject: RE: Response code when POSTing existing resource
Thread-Topic: Response code when POSTing existing resource
Thread-Index: AQHNCvvlLoZiwEKFY06kbfhd3F53K5Z8nPMAgAAX2gCACyb2AIAlQfIAgAANOICAAFwr8IAABvKAgAAAgFA=
Date: Thu, 26 Apr 2012 17:56:17 +0000
Message-ID: <51D30573C07F2D41A6DE9D263913295328426...@CH1PRD0310MB380.namprd03.prod.outlook.com>
References: <551691cb-5469-458c-9c77-82e6c7573...@n5g2000vbf.googlegroups.com>
	<23002568.219.1332770712450.JavaMail.geo-discussion-forums@vblo18>
	<b207f290-a558-4a3b-bcc3-fb943ef9b...@do4g2000vbb.googlegroups.com>
	<B6AE84A0-9B92-4723-A483-A921E941E...@gmail.com>
	<29235383.1503.1335437190987.JavaMail.geo-discussion-forums@vbq5>
	<CANqiZJbNC8LGwXfjCxBSJ4FUNEjzCRr5WxDkPwaSCd8+8eu...@mail.gmail.com>
	<51D30573C07F2D41A6DE9D263913295328426...@CH1PRD0310MB380.namprd03.prod.outlook.com>
 <CANqiZJYB6WW=MFwnRY4i3z3peRtcqhfKARjC+bqbOFHHgSk...@mail.gmail.com>
In-Reply-To: <CANqiZJYB6WW=MFwnRY4i3z3peRtcqhfKARjC+bqbOFHHgSk...@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0

<snip>
Sorry, do you mean this is an 'issue' because you can't smoothly switch a r=
esource's behaviour from sync w/ 200 to async w/ 202? You're right, that is=
 impractical ! :)
</snip>

No, I mean that this is an issue because if I ever use a 202 response code =
to a request on an API for which I don't own the clients, then invariably p=
eople write clients that include code like:

if(response.status / 100 =3D=3D 2) { // 2xx
	handlers.success(response.head, response.body);
} else {
	// possibly differentiate between 3xx, 4xx, and 5xx here, or not.
	handlers.fail(response.head, response.body);
}

And then they get subtle errors and they (and their users) complain that th=
ere's a bug in the service (it isn't reporting an error when one happens).

If I can control or strongly influence the clients then I can use all sorts=
 of HTTP features (partial GET, async processing, etc) that I can't use whe=
n I'm targeting a general client audience.

Arlo

-----Original Message-----
From: api-craft@googlegroups.com [mailto:api-craft@googlegroups.com] On Beh=
alf Of Mike Kelly
Sent: Thursday, April 26, 2012 10:29 AM
To: api-craft@googlegroups.com
Subject: Re: Response code when POSTing existing resource

Hi Ario,

On Thu, Apr 26, 2012 at 6:12 PM, Arlo Belshee <Arlo.Bels...@microsoft.com> =
wrote:
> Well, "2xx means OK" includes one misconception. It ignores 202, which in=
tentionally states that the error state is currently unknown.

2xx doesn't mean OK, 2xx means success - which is what the spec says:

"This class of status code indicates that the client's request was successf=
ully received, understood, and accepted."

Either way, Duncan's advice to use 2xx in response to a client error is wro=
ng.

> The fact that lots of client developers think "2xx =3D=3D OK" makes it di=
fficult to write servers that really do async processing. 202 is great if y=
ou own the clients. If you're handling generic clients, the "install base" =
of client developer thinking is too entrenched to really let you use it.
>
> Thus people end up lifting async (a processing concern) to the resource l=
evel. They create resources like "transaction" or "batch" so that they can =
represent async without using the HTTP async primitives.
>
> Oh well - another case where HTTP usable in practice is only a subset of =
HTTP in spec.

Sorry, do you mean this is an 'issue' because you can't smoothly switch a r=
esource's behaviour from sync w/ 200 to async w/ 202? You're right, that is=
 impractical ! :)

Cheers,
Mike