Re: HTTP code for error business logic

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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
>>
>>

Attachment: signature.asc
Description: PGP signature


[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Mhonarc]     [Fedora Users]

  Powered by Linux