On Mon, Apr 20, 2020 at 10:36 AM Darshana Gunawardana <darsh...@wso2.com>
wrote:
>
>
> On Thu, Nov 21, 2019 at 10:46 AM Malithi Edirisinghe <malit...@wso2.com>
> wrote:
>
>> Hi All,
>>
>> I'm wondering if we should classify error codes based on client errors in
>> user APIs, server errors in user APIs, client errors in server APIs and
>> server errors in server APIs.
>> With such separation we are making things more complex.
>> The idea here is to just to have some convention, a consistent error code
>> model and to improve developer experience.
>> So for that I think the error code just need to reflect if it's a client
>> type error or a server type error and the relation with the API
>>
>> So my understanding is like below.
>> We have APIs that will be consumed by end users.
>> And we have APIs that are consumed by some privileged user or system user.
>> Underlying, each of these APIs would consume the OSGI services. So, a
>> specific OSGI service can be consumed either by an end user API,
>> privileged or system user API, or both.
>>
>> So, at the OSGI service layer, the classification we can do is only of
>> whether it is a client type error or a server type error.
>> Then at the REST API layer, client type errors will be identified and
>> reflected, subjected to sensitivity case by case.
>> Server type errors will be identified and reflected with very minimal
>> information or under a common message. That would be based on whether we
>> need to reflect such info to the client.
>> So it's the responsibility of the REST API layer to decide how to reflect
>> an error thrown from the OSGI service layer.
>>
>> Therefore, if we try to classify user type and server type client errors
>> and server errors in the OSGI layer, there will be a lot of confusion on
>> what type of code to use in the OSGI service layer.
>> Also, we will have to do additional error code mappings at the REST API
>> layer.
>>
>> Thus, I think, we just need to have a range defined for client type
>> errors and server type errors.
>> OSGI service layer will just throw based on that range.
>> Qualify the error code sent externally at the REST API layer. If the
>> exact error thrown from asn OSGI service needs be uniquely identified we
>> can have a qualifier at that level and remap only the qualified at REST API
>> layer, or have some component no or something included in the error code.
>> But other than that there's no necessity in re-mapping error codes coming
>> from OSGI layer at the REST API layer.
>> And it would be really easy to understand,
>> - what type of error it is,
>> - which could be the API throwing this error
>> at a glance.
>>
>> Thanks,
>> Malithi.
>>
>>
>> On Tue, Nov 5, 2019 at 4:01 PM Vihanga Liyanage <viha...@wso2.com> wrote:
>>
>>> Hi all,
>>>
>>> As per the discussion we had today, we've decided to do the following
>>> changes in server error codes.
>>>
>>> *Client errors in server APIs*
>>>
>>> For client errors in server APIs, we have allocated the range starting
>>> from 600.
>>>
>>> Eg: USR-600xx
>>>
>>> *Server Errors in server APIs*
>>>
>>> For server errors in server APIs, we have allocated the range starting
>>> from 650.
>>>
>>> Eg: USR-650xx
>>>
>>>
>>> Regards,
>>>
>>> Vihanga.
>>>
>>> On Mon, Nov 4, 2019 at 9:10 AM Vihanga Liyanage <viha...@wso2.com>
>>> wrote:
>>>
>>>> +1
>>>> But we should change the existing APIs if we're going with this.
>>>>
>>>> On Fri, Nov 1, 2019 at 11:32 AM Isura Karunaratne <is...@wso2.com>
>>>> wrote:
>>>>
>>>>> Hi Sominda,
>>>>>
>>>>> I think it is better to start all the client errors with 400 (Ex
>>>>> USR-400xx) and server errors with 500 (Ex USR-500xx). In this way, we
>>>>> can get some understanding of the error by looking at the error code.
>>>>>
>>>>> Cheers,
>>>>> Isura.
>>>>>
>>>>> On Thu, Aug 29, 2019 at 2:44 PM Sominda Gamage <somi...@wso2.com>
>>>>> wrote:
>>>>>
>>>>>> Hi all,
>>>>>>
>>>>>> Currently, the REST APIs of Identity Server have different error
>>>>>> codes such as (20018, 20048, etc.). The error codes in this format have
>>>>>> less information regarding the cause or where it has occurred.
>>>>>>
>>>>>> Therefore, we would like to maintain the error codes which are used
>>>>>> in our REST APIs in one commonplace. Currently, we are standardizing
>>>>>> error
>>>>>> codes along with their details and this is still a work in progress.
>>>>>>
>>>>>> According to this effort, sample error code will look like “
>>>>>> <Prefix>-<error-identifier-number>
>>>>>>
>>>>>> Eg: CQM-10005
>>>>>>
>>>>>> The Prefix (first part) indicates the component. In this case, CQM
>>>>>> indicates Challenge Questions Management.
>>>>>> The error-identifier-number (the second part of the error code)
>>>>>> reflects the numerical identifier for the error.
>>>>>>
>>>>>> For the rest APIs, we have defined 2 types of codes for both user and
>>>>>> server APIs.
>>>>>>
>>>>>> -
>>>>>>
>>>>>> Success codes: For successful operations
>>>>>> -
>>>>>>
>>>>>> Error codes: For error scenarios
>>>>>> -
>>>>>>
>>>>>> Client Errors
>>>>>> -
>>>>>>
>>>>>> Server Errors
>>>>>>
>>>>>>
>>>>>>
>>>>>> *Success Codes*
>>>>>>
>>>>>> Despite the API type, all the success codes will start from 02000
>>>>>> onwards. To maintain consistency, a zero will be added at the beginning.
>>>>>>
>>>>>> Eg: USR-02001
>>>>>>
>>>>>> The above Success Code indicates a successful User Self Registration.
>>>>>>
>>>>>>
>>>>>> *Error Codes*
>>>>>>
>>>>>> With the introduction of API error standards, we wish to standardize
>>>>>> the error response from an API. Therefore, a sample API error response
>>>>>> will
>>>>>> be as follows.
>>>>>>
>>>>>> {
>>>>>>
>>>>>> “code” : “some_error_code”,
>>>>>>
>>>>>> “Message” : “some_error_message”,
>>>>>>
>>>>>> “Description” : “some_error_description”,
>>>>>>
>>>>>> “traceID” : “correlation_id”
>>>>>>
>>>>>> }
>>>>>>
>>>>>> A correlationId has been introduced to log the error and send with
>>>>>> the response
>>>>>>
>>>>>>
>>>>>> *User API errors*
>>>>>>
>>>>>> User APIs has two types of errors.
>>>>>>
>>>>>> 1.
>>>>>>
>>>>>> Client errors
>>>>>> 2.
>>>>>>
>>>>>> Server errors
>>>>>>
>>>>>> *Client Errors in user APIs*
>>>>>>
>>>>>> For client errors in user APIs, we have allocated the range starting
>>>>>> from 100.
>>>>>>
>>>>>> Eg: USR-100xx
>>>>>>
>>>>>> *Server Errors in user APIs*
>>>>>>
>>>>>> For server errors in user APIs, we have allocated the range starting
>>>>>> from 100.
>>>>>>
>>>>>> Eg: USR-150xx
>>>>>>
>>>>>>
>>>>>> *Server API Errors*
>>>>>>
>>>>>> Server APIs has two types of errors.
>>>>>>
>>>>>> 1.
>>>>>>
>>>>>> Client errors
>>>>>> 2.
>>>>>>
>>>>>> Server errors
>>>>>>
>>>>>> *Client errors in server APIs*
>>>>>>
>>>>>> For client errors in server APIs, we have allocated the range
>>>>>> starting from 500.
>>>>>>
>>>>>> Eg: USR-500xx
>>>>>>
>>>>>> *Server Errors in server APIs*
>>>>>>
>>>>>> For server errors in server APIs, we have allocated the range
>>>>>> starting from 550.
>>>>>>
>>>>>> Eg: USR-550xx
>>>>>>
>>>>>>
>>>>>> This will be the new standardization for Rest API Success and Error
>>>>>> responses.
>>>>>>
>>>>>>
>>>>>> Thanks & Regards,
>>>>>>
>>>>>> Sominda.
>>>>>>
>>>>>> --
>>>>>> *Sominda Gamage* | Software Engineer| WSO2 Inc. <http://wso2.com/>
>>>>>> (M)+94 719873902 | (E) somi...@wso2.com
>>>>>> <https://wso2.com/signature>
>>>>>> _______________________________________________
>>>>>> Architecture mailing list
>>>>>> Architecture@wso2.org
>>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>>
>>>>> *Isura Dilhara Karunaratne*
>>>>> Technical Lead | WSO2 <http://wso2.com/>
>>>>> *lean.enterprise.middleware*
>>>>> Email: is...@wso2.com
>>>>> Mob : +94 772 254 810
>>>>> Blog : https://medium.com/@isurakarunaratne
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Architecture mailing list
>>>>> Architecture@wso2.org
>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>>>
>>>>
>>>>
>>>> --
>>>>
>>>> Vihanga Liyanage
>>>>
>>>> Senior Software Engineer | WS*O₂* Inc.
>>>>
>>>> M : +*94710124103* | http://wso2.com
>>>>
>>>> [image: http://wso2.com/signature] <http://wso2.com/signature>
>>>>
>>>
>>>
>>> --
>>>
>>> Vihanga Liyanage
>>>
>>> Senior Software Engineer | WS*O₂* Inc.
>>>
>>> M : +*94710124103* | http://wso2.com
>>>
>>> [image: http://wso2.com/signature] <http://wso2.com/signature>
>>> _______________________________________________
>>> Architecture mailing list
>>> Architecture@wso2.org
>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>
>>
>>
>> --
>> *Malithi Edirisinghe* | Technical Lead | WSO2 Inc.
>> (m) +94 718176807 | (w) +94 11 214 5345 | (e) malit...@wso2.com
>> GET INTEGRATION AGILE
>> Integration Agility for Digitally Driven Business
>> _______________________________________________
>> Architecture mailing list
>> Architecture@wso2.org
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
>
>
> --
> Regards,
>
>
> *Darshana Gunawardana*Technical Lead
> WSO2 Inc.; http://wso2.com
>
> *E-mail: darsh...@wso2.com <darsh...@wso2.com>*
> *Mobile: +94718566859*Lean . Enterprise . Middleware
> _______________________________________________
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
--
Sathya Bandara
Senior Software Engineer
Blog: https://medium.com/@technospace
WSO2 Inc. http://wso2.com
Mobile: (+94) 715 360 421
<+94%2071%20411%205032>
_______________________________________________
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
