On Thu, Nov 21, 2019 at 10:46 AM Malithi Edirisinghe <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> >>> 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 <[email protected]> >>>> 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) [email protected] >>>>> <https://wso2.com/signature> >>>>> _______________________________________________ >>>>> Architecture mailing list >>>>> [email protected] >>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>> >>>> >>>> >>>> -- >>>> >>>> *Isura Dilhara Karunaratne* >>>> Technical Lead | WSO2 <http://wso2.com/> >>>> *lean.enterprise.middleware* >>>> Email: [email protected] >>>> Mob : +94 772 254 810 >>>> Blog : https://medium.com/@isurakarunaratne >>>> >>>> >>>> >>>> _______________________________________________ >>>> Architecture mailing list >>>> [email protected] >>>> 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 >> [email protected] >> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >> > > > -- > *Malithi Edirisinghe* | Technical Lead | WSO2 Inc. > (m) +94 718176807 | (w) +94 11 214 5345 | (e) [email protected] > GET INTEGRATION AGILE > Integration Agility for Digitally Driven Business > _______________________________________________ > Architecture mailing list > [email protected] > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > -- Regards, *Darshana Gunawardana*Technical Lead WSO2 Inc.; http://wso2.com *E-mail: [email protected] <[email protected]>* *Mobile: +94718566859*Lean . Enterprise . Middleware
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
