Thanks for you detail feedback will definitely look it in detail . Thanks for sharing this approach will try to implement same as and when arise such scenarios.
Original Message:
Sent: Sep 06, 2024 08:01
From: Matthieu Hattab
Subject: How To Extend Error Response Payload With Optional Attribute
Hello,
I understand your use case is about credit check and how to "merge" the various "errors" from dependent services.
First, I'd to recommend to avoid using the term "error". because it's not an error. It's a validation result.
I don't recommend following TMF630 as a guide for mananing errors as these are not errors.
error should only refer to HTTP status codes.
for credit check, we don't have error but validation result, wich could be a rating, a scope, a status etc.
what you need is a sub-resource in your API contract that represent a list of validation type/reaons/code/... representing the rating of the customer.
if you need suggestion on how to represent credit check validation, you can take inspiration from existing API that contain validation result:
- TMF679 (product offering qualification) has validation result about product offer eligibility
- TMF645 (service qualifiation) has validation about technical feasability
- TMF760 (Product Configuration) has dedicated sub resource for credit check
we use these API and have made some small extension to provide additional details. the model is quite flexible.
As for your question about aggregating validations. we have adopted this approach:
we created a composite qualification API that bundles TMF679 (only the qualification part) and TMF645.
the composite has both payloads and also has an aggregator of all validations. Composition solves 2 issues
- API clients have a single endpoint
- we solve TMF APIs inconsistencies in the semantic
- 645 has a sub-resource called EligibilityResultReason while 679 use another name: EligibilityUnavailabilityReason
- but both resource have the same attributes: code and reason to which we added status and period
You can add sub-resource and attributes (we added 2 attributes: status and period).
Lastly if you want to keep your TMF API conformant, you can check the "conformance profile (RAND)" pdf document provided in the TMF API table.
Hope this helps,
------------------------------
Kind regards,
Matthieu Hattab
Lyse Platform
Original Message:
Sent: Sep 04, 2024 04:04
From: Pritam Roy
Subject: How To Extend Error Response Payload With Optional Attribute
We would like to get your inputs on a requirement to send additional information as part of the error response.
We have a synchronous API which internally performs the below API callouts in the order mentioned below.
- Get Quote details
- Perform Credit Check
- Update Credit Check Result into quote
- Update Payment Method Status
- Take Payment
- Submit Quote to Product Order
Now, the ask is if any of the steps from 3 to 6 failed, we need to send "what is the reason of failure + what is the credit check result from step 2"
- Below is the existing sample error response defined for step 3 failure.
{
"code": "EditQuoteError",
"reason": "Error in editing quote",
"message": "Error in editing quote",
"status": "500"
}
- In the above error response, if we have to indicate credit check result from step 2, how can we do it?
- Are we allowed to extend the error response to add an optional attribute like creditCheckResult as below?
- Does it violate TMF OpenAPI error structure?
- Or any other standard guideline we have as per TMF OpenAPI ?
{
"code": "EditQuoteError",
"reason": "Error in editing quote",
"message": "Error in editing quote",
"status": "500",
"creditCheckResult': "RED"
}
------------------------------
Pritam Roy
Principal Solution Architect
Tech Mahindra Limited
------------------------------