TM Forum Community

 View Only

  • 1.  Error handling for different consumers of same API

    TM Forum Member
    Posted Oct 31, 2023 12:17
    Edited by Ilyas Premji Nov 03, 2023 05:39

    Hello,

    If there is a TMF API (say TMF622) which is used for different consumers and each consumer expects different error messages for the same functionality, can someone advice on what the best way is for error handling?

    For now, we have these 2 options on mind:

    1. Hard coding the different error messages per consumer
    2. Creating a reference data, to differentiate the error messages per consumer, even if there is no reuse (today).

    Thanks in advance!


    #OpenDigitalArchitecture

    ------------------------------
    Manaswini Jayaraman
    Proximus SA
    ------------------------------



  • 2.  RE: Error handling for different consumers of same API

    TM Forum Member
    Posted Nov 13, 2023 05:26

    Hi Manaswini

    I would posit that this is not a recommended approach in integration architecture. Basically you end up creating a very strong dependency between the provider and the consumer.

    In my view, the provider should be able to advertise all the different error conditions that can happen as a result of (say) POSTing a ProductOrder. It's now up to each consumer to decide what it will do with errors that are returned.

    Hope it helps



    ------------------------------
    Jonathan Goldberg
    Amdocs Management Limited
    Any opinions and statements made by me on this forum are purely personal, and do not necessarily reflect the position of the TM Forum or my employer.
    ------------------------------

    Original Message


  • 3.  RE: Error handling for different consumers of same API

    TM Forum Member
    Posted Nov 14, 2023 04:01
    Edited by Vance Shipley Nov 15, 2023 02:08

    Which "error messages" are you referring to?  You should not change the HTTP Status Code (e.g. 404).

    TMF630 v4.2.0 section 3.4 describes User, Application and Extended Error Codes which are provided as a JSON object in the body of the response:

    {
        "code": 
        "reason": 
        "message": 
        "status":  
        "reference": 
        "@type": 
        "@schemaLocation": 
    }

    You could tailor this however the question becomes: based on what?  If your server responds differently from request to request it breaks determinism.  The proper way to handle that is to use Media Types. TMF630 specifies application/json however you could use Content Negotiation to add additional types.  We do this at SigScale to allow clients to request IETF Problem Details (RFC7807) encoding, as used by 3GPP and ETSI (see AP-2628).  The client would add the media type (application/problem+json) to it's accepted media types in the request:

    POST /productOrder
    Content-Type: application/json
    Accept: application/problem+json, application/json

    This tells the server that a response body may contain the IETF Problem details JSON object or the TMF Forum JSON object. The server response shall indicate which in the Content-Type header:

    HTTP/1.1 400 Bad Request
    Content-Type: application/problem+json

    You could use your own media type(s) (e.g. application/vnd.acme.problem) or you could extend the TMF type with a parameter (e.g. schema=acmeError) (although RFC4627 doesn't specify any, so this is an invention):

    POST /productOrder
    Content-Type: application/json
    Accept: application/json;schema=AcmeError

    You could then extend the JSON Schema (Common/Error.schema.json) polymorphically with whatever extra attributes you wanted:

    {
        "@type": "AcmeError",
        "@schemaLocation": "/schema/AcmeError.schema.json",
         "acmeCode": 42,
        ...
    }

    If you use a polymorphic extension you wouldn't need to use content negotiation as all as long at it's OK to send the same extended response to all clients.  Clients which don't understand AcmeError should ignore the extra attributes, however they may request exactly the type (i.e. AcmeError) they prefer to accept.



    ------------------------------
    Vance Shipley
    SigScale
    ------------------------------

    Original Message