Thank you very much for your comments.
чт, 15 авг 2019 г., 16:51 Alexander Neilson alexander@xxxxxxxxxxxxxx:
Hi IlyaBased on the register of codes 452 isn’t assigned. (Unfortunately my Cyrillic isn’t good enough to work through the endnote reference for 452)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 invalid2: 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.RegardsOn 16/08/2019, at 00:45, Илья Страхов <ilya.strahov@xxxxxxxxx> wrote: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_HTTPHi 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.
2019-08-15 14:01 GMT+03:00, Илья Страхов <ilya.strahov@xxxxxxxxx>:The correct dimension, data type, syntax are passed to the applicationside. In the process of processing, business logic errors may occur,for each service there may be different options depending on thespecifics: warehouse accounting, payments, charging, etc. 1) could Notcreate a dependent entity, because the entity to which the clientrefers is not the essence. Data has been out of sync between systems.2) Transferred amount (number, pieces, etc) cannot be accepted. 3) theUser is blocked. 4) Heated discussion on the absence of an object,instead of 404 you can give a newcode. 5) you Cannot set the passedstatus for an entity. 6) the Entity has already been activated.2019-08-15 12:18 GMT+03:00, Alexander Neilson <alexander@xxxxxxxxxxxxxx>:On 15/08/2019, at 20:12, Илья Страхов <ilya.strahov@xxxxxxxxx> wrote:Hello.I want to hear the opinion of the community and offer a separate HTTPcode for the situation when the client has sent data that on the sideof 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 theHTTP 400 response. It's okay.2) If the client passed the key and value, further data processing ledto an error when the entity cannot be created/modified for reasons atthe application logic level. For this case, I propose to make a newHTTP code.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 itseems to me that 400 would still be suitable.So if you could elaborate on what sort of different failure you arehandlingwhen processing the data and how this would be clearly defined foranother4XX code to be usefully handled by processing consumers this may assistothers in looking at supporting this suggestion.RegardsAlexanderAlexander NeilsonNeilson Productions Limited021 329 681alexander@xxxxxxxxxxxxxx
