[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: POST for an exisiting id?
- To: atom-protocol <atom-protocol@xxxxxxx>
- Subject: Re: POST for an exisiting id?
- From: "Thomas Broyer" <t.broyer@xxxxxxxxx>
- Date: Wed, 2 Jan 2008 21:45:30 +0100
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=oyh0LsSINgaG53uOi49g+/dCI/G9C3zogMfQm3mn0B8=; b=YQS+CWHAYn2KlBI7MrvPqFrmZ/gcYUfFrOZj+lOydfDKiZu9ttYG3FPe62ZPh/H2BKBPzGfYyfnYkl7ptEp1Ep10dAoV9cl4zLBal0hLL9uJZKjh+GUxVAofikrOLzKpQFkmUCqEcs0D4joi+3SiDOVzZhdSYaCXmUldo2Ey+JQ=
- Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=S7lbHjYieUkJEba1agXHrYctbU4eANp+EDy8+pjREsyL5+zVuNnAo84TmJk/vjCS0moh3kV9gB1t/vWhy7R+2EVf8QHUsAj3YwJznRulIPKqsXxPyQN0q/6pG0fqdREFswGsDxD87P7znB8o0Ss/MBp+yNEFnr6Qozip63niAMU=
- In-reply-to: <20080102200933.1291861785@xxxxxxxxxxxxxxxxxxx>
- List-archive: <http://www.imc.org/atom-protocol/mail-archive/>
- List-id: <atom-protocol.imc.org>
- List-unsubscribe: <mailto:atom-protocol-request@imc.org?body=unsubscribe>
- References: <20080102200933.1291861785@xxxxxxxxxxxxxxxxxxx>
- Sender: owner-atom-protocol@xxxxxxxxxxxx
2008/1/2, Dirk Haun:
>
> Apologies if I'm missing anything obvious, but I'm just sitting here
> brooding over an Atom Protocol Exerciser Report and wondering "what does
> it want from me?"
>
> The APE's Mini One / Mini Two test apparently POSTs a second entry for
> an already existing one (with the same id). Since RFC5023 states that
> POST is for creation and PUT is for modification, I'm wondering what to
> do in that situation.
>
> We're currently returning a "400 Bad Request" but that doesn't make the
> APE happy.
I don't know what the APE waits for, but 400 is fine. 409 (Conflict)
or 422 (Unprocessable entity; from RFC 2518) might feel better but 400
is good enough.
--
Thomas Broyer