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
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 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 <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 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.
>>
>> 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
>> alexander@xxxxxxxxxxxxxx
>>
>>
>
