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
