- From: Mark Nottingham <mnot@mnot.net>
- Date: Thu, 4 Aug 2022 12:20:40 +1000
- To: Roberto Polli <roberto@teamdigitale.governo.it>
- Cc: "Julian F. Reschke" <julian.reschke@gmx.de>, HTTP Working Group <ietf-http-wg@w3.org>
> On 4 Aug 2022, at 5:45 am, Roberto Polli <roberto@teamdigitale.governo.it> wrote: > > Do you think it's worth doing this? > Do you thing 207 is something that is reasonable to use e.g. when replying to requests affecting and/or related to different resources? This has come up before. The problem with 207 is that it hides the semantics of the enclosed responses from generic software, so it really isn't serving any function as a status code. In that sense, 200 would be equally sufficient -- the only distinguishing semantic of 207 (once made generic) is that 'this message has more than one status code, so you can't trust the status code on it to be descriptive) -- a distinction that most generic software is going to miss, so they'll consider it 200 anyway (as a 2xx status code). There's also been extensive discussion of 'batching', which 207 is usually a sign of. It's not a great practice, for the reasons above. Best practice depends on what you're trying to do specifically, but generally if you're trying to describe side effects on other resources, the best thing to do is to do so as appropriate in your responses (using headers, the response payload, etc.). Those are application-specific things, though, not things that surface at the generic HTTP semantic layer. Cheers, -- Mark Nottingham https://www.mnot.net/
Received on Thursday, 4 August 2022 02:21:00 UTC