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)
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.
022 456 2326
On Thu, 15 Aug 2019 at 23:23, Cenk Gündoğan <mail+ietf@xxxxxxxxxxxx> wrote:
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
On Thu, Aug 15 2019 at 13:01 +0200, Илья Страхов wrote:
> 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
>>
>>
