Subject: HTTP code for error business logic

From: Илья Страхов <[email-masked]>
Date: Thu, 15 Aug 2019 11:12:03 +0300

Hello.
I want to hear the opinion of the community and offer a separate HTTP
code for the situation when the client has sent data that on the side
of business logic is processed with an error.

An example in the context of the REST.
1) If the client did not pass a required key or syntax error, then the
HTTP 400 response.  It's okay.
2) If the client passed the key and value, further data processing led
to an error when the entity cannot be created/modified for reasons at
the application logic level. For this case, I propose to make a new
HTTP code.

---

From: Alexander Neilson <[email-masked]>
Date: Thu, 15 Aug 2019 21:18:46 +1200

> On 15/08/2019, at 20:12, Илья Страхов <[email-masked]> wrote:
> 
> Hello.

Can you please expand more on what kind of application logic error?

For example if the value is invalid for that key (whether out of range, wrong type, is external reference where reference doesn’t exist) then it seems to me that 400 would still be suitable. 

So if you could elaborate on what sort of different failure you are handling when processing the data and how this would be clearly defined for another 4XX code to be usefully handled by processing consumers this may assist others in looking at supporting this suggestion. 

Regards
Alexander

Alexander Neilson
Neilson Productions Limited
021 329 681
[email-masked]

---

From: Илья Страхов <[email-masked]>
Date: Thu, 15 Aug 2019 14:01:24 +0300

The correct dimension, data type, syntax are passed to the application
side. In the process of processing, business logic errors may occur,
for each service there may be different options depending on the
specifics: warehouse accounting, payments, charging, etc. 1) could Not
create a dependent entity, because the entity to which the client
refers is not the essence. Data has been out of sync between systems.
2) Transferred amount (number, pieces, etc) cannot be accepted. 3) the
User is blocked.  4) Heated discussion on the absence of an object,
instead of 404 you can give a newcode. 5) you Cannot set the passed
status for an entity.  6) the Entity has already been activated.

2019-08-15 12:18 GMT+03:00, Alexander Neilson <[email-masked]>:
> For example if the value is invalid for that key (whether out of range,
> wrong type, is external reference where reference doesn’t exist) then it
> seems to me that 400 would still be suitable.
>
> So if you could elaborate on what sort of different failure you are handling
> when processing the data and how this would be clearly defined for another
> 4XX code to be usefully handled by processing consumers this may assist
> others in looking at supporting this suggestion.
>
>>
>
>
> Regards
> Alexander
>
> Alexander Neilson

---

From: Cenk Gündoğan <[email-masked]>
Date: Thu, 15 Aug 2019 13:23:47 +0200

Hello Ilya,

I might be completely off-track with this .. but aren't WSDL and BPML
two of many solutions on the application layer for exactly these things
you described?

Cheers,
Cenk

---

From: Alexander Neilson <[email-masked]>
Date: Thu, 15 Aug 2019 23:47:16 +1200

Hi Ilya

Looking at your list I think were you simply wanting a different 4XX status
code that would be used for any rejection above the HTTP server itself and
you would still be providing a response message in the body to detail the
problem?

(or to clarify you want another 400 which separates the two levels:
e.g.

mandatory key (type int) provided as string = 400 response as filtered by
HTTP server during deserialisation
mandatory key (type int) provided however the value is not permitted for
the user to access = 4XX response (new code) as handled by internal system

?

If I have this correct I think because of the range of scenarios this new
code would be used for is so wide then the explanation would need to be
passed to the user / parsed carefully there is less benefit to adding an
additional code because either way the request was malformed / incorrect

1) could Not create a dependent entity, because the entity to which the
client refers is not the essence. Data has been out of sync between
systems. (400 or 409)
2) Transferred amount (number, pieces, etc) cannot be accepted. (400)
3) the User is blocked. (403)
4) Heated discussion on the absence of an object, instead of 404 you can
give a newcode. (404, 410)
5) you Cannot set the passed status for an entity. (405, 403, 400)
6) the Entity has already been activated. (409)

I have thrown in some codes above that I think could be used for these
situations (based on my understanding on what you were suggesting), because
of the wide proposed use of the new code I would tend to lean away from
issuing a new code thinking the current codes provide a fairly good range
of options to respond which isn't made clearer by the new "business logic"
4XX code and the balance with getting implementation by other systems vs
using the existing codes isn't yet weighted enough in the favour of this
particular new code.

I am happy to be convinced if there is a clear suggestion of a code with
clear meaning where the difference isn't only dependent on the structure of
the system handling the query.

Regards
Alexander

Alexander Neilson

[email-masked]
021 329 681
022 456 2326

On Thu, 15 Aug 2019 at 23:23, Cenk Gündoğan <[email-masked]> wrote:

> > 2019-08-15 12:18 GMT+03:00, Alexander Neilson <[email-masked]
> >:
> >>
> >>

---

From: Илья Страхов <[email-masked]>
Date: Thu, 15 Aug 2019 15:45:03 +0300

Hi Alexander
You understand correctly, I think it would be useful to explicitly
separate two situations: request validation with HTTP error code 400
and other business logic errors. Of course, the new code can be
interpreted broadly, but for clarification, you can give an exhaustive
answer in the body.  I am quite suitable definition that I found in
the Russian Wikipedia 452 Bad send request ("Sent unacceptable data")
But for some reason there are no references to the source. Perhaps you
know something about the code 452 ?

https://ru.wikipedia.org/wiki/%D0%A1%D0%BF%D0%B8%D1%81%D0%BE%D0%BA_%D0%BA%D0%BE%D0%B4%D0%BE%D0%B2_%D1%81%D0%BE%D1%81%D1%82%D0%BE%D1%8F%D0%BD%D0%B8%D1%8F_HTTP

Hi Ilya

?

---

From: Alexander Neilson <[email-masked]>
Date: Fri, 16 Aug 2019 01:51:51 +1200

Hi Ilya

Based on the register of codes 452 isn’t assigned. (Unfortunately my Cyrillic isn’t good enough to work through the endnote reference for 452)

https://www.iana.org/assignments/http-status-codes/http-status-codes.xhtml

To my read (of the name) 452 code would be recorded under 400 under current code point utilisation. 

You could author an ID proposing IANA issue 452 officially (whether with that name from Russian Wikipedia or another). I would suggest clearly identifying that:
1: this response code MUST be used where the request is correctly formatted (as per specification) however further processing results in discovering that the request is in fact invalid
2: this code SHOULD NOT be used in cases where another code point provides a clearer response to the user (eg 403 would be a better use for a permissions failure)
3: this “business logic” code MUST include a body providing an explanation of the cause of the error including the key and reason for failure

(Feel free to ignore my advice here, but crafting this way fits into my mental model of how this code should be used - if issued)

Others may provide other advice. 

Regards
Alexander

Alexander Neilson

> On 16/08/2019, at 00:45, Илья Страхов <[email-masked]> wrote:
> 
> Hi Alexander

---

From: Илья Страхов <[email-masked]>
Date: Thu, 15 Aug 2019 21:49:48 +0300

Thank you very much for your comments.

чт, 15 авг 2019 г., 16:51 Alexander Neilson [email-masked]:

> Hi Ilya
>
> Based on the register of codes 452 isn’t assigned. (Unfortunately my
> Cyrillic isn’t good enough to work through the endnote reference for 452)
>
> You could author an ID proposing IANA issue 452 officially (whether with
> that name from Russian Wikipedia or another). I would suggest clearly
> identifying that:
> 1: this response code MUST be used where the request is correctly
> formatted (as per specification) however further processing results in
> discovering that the request is in fact invalid
> 2: this code SHOULD NOT be used in cases where another code point provides
> a clearer response to the user (eg 403 would be a better use for a
> permissions failure)
> 3: this “business logic” code MUST include a body providing an explanation
> of the cause of the error including the key and reason for failure
>
> (Feel free to ignore my advice here, but crafting this way fits into my
> mental model of how this code should be used - if issued)
>
> So if you could elaborate on what sort of different failure you are
>
> handling
>
> when processing the data and how this would be clearly defined for
>
> another
>

---

From: "Matthew A. Miller" <[email-masked]>
Date: Thu, 15 Aug 2019 15:19:30 -0600

Hello all,

We ask that you continue the discussion about HTTP status codes on the httpbis mailing list < [email-masked] > as that is a more appropriate venue for HTTP work.  As noted in RFC 3005, the IETF general list is acceptable unless a more appropriate e-mail venue is available.

Note this list is operated by the W3C, so subscribing to it and reviewing the archives are different from other IETF mailing lists.  It is still subject to the IETF Note Well.
* Archives: < http://lists.w3.org/Archives/Public/ietf-http-wg/ >
* To subscribe: < mailto:[email-masked]?subject=subscribe >

Regards,

- Matthew A. Miller
Sergeant-at-Arms

> On Aug 15, 2019, at 12:49, Илья Страхов <[email-masked]> wrote:
> 
> чт, 15 авг 2019 г., 16:51 Alexander Neilson [email-masked] <mailto:[email-masked]>:
> Hi Ilya
> 
> https://www.iana.org/assignments/http-status-codes/http-status-codes.xhtml <https://www.iana.org/assignments/http-status-codes/http-status-codes.xhtml>
> 
> [email-masked] <mailto:[email-masked]>
> 
>> On 16/08/2019, at 00:45, Илья Страхов <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> Hi Alexander
>> https://ru.wikipedia.org/wiki/%D0%A1%D0%BF%D0%B8%D1%81%D0%BE%D0%BA_%D0%BA%D0%BE%D0%B4%D0%BE%D0%B2_%D1%81%D0%BE%D1%81%D1%82%D0%BE%D1%8F%D0%BD%D0%B8%D1%8F_HTTP <https://ru.wikipedia.org/wiki/%D0%A1%D0%BF%D0%B8%D1%81%D0%BE%D0%BA_%D0%BA%D0%BE%D0%B4%D0%BE%D0%B2_%D1%81%D0%BE%D1%81%D1%82%D0%BE%D1%8F%D0%BD%D0%B8%D1%8F_HTTP>
>> 
>>>>> 
>> Hi Ilya
>> 
>> 2019-08-15 14:01 GMT+03:00, Илья Страхов <[email-masked] <mailto:[email-masked]>>:
>>> 2019-08-15 12:18 GMT+03:00, Alexander Neilson <[email-masked] <mailto:[email-masked]>>:
>>>> 
>>>> 
>>>>> On 15/08/2019, at 20:12, Илья Страхов <[email-masked] <mailto:[email-masked]>> wrote:
>>>>> 
>>>>> Hello.
>>>> [email-masked] <mailto:[email-masked]>
>>>> 
>>>> 
>>>