Error format depending on the error type

Vito
Regular Visitor

Error format depending on the error type

Hi,

 

I have a question regarding the Error code response format. Each service comes with an OpenApi specification for errors but in some edge cases, a more general error might occur. I am thinking of MLE problems or right now I hit an error because the service I wanted to test does not have a sandbox environment. However the error format was different from the API specifications and my deserialization failed.

 

Is there another format that I can use for deserialization across services, if do not get a MLE response from a service? Or do I need to implement some other logic, for example, if I do not receive a success HTTP response, I should try deserializing the Error code to the OpenApi format, if that fails just log the raw string?

 

And if it's not a MLE service, how can I know, which Error format should I be expecting?

 

Regards

2 REPLIES 2
SyedSa
Community Moderator

Re: Error format depending on the error type

Hi @VitoThank you for reaching out. An agent will get back to you as soon as possible. Until then, if any community member has information that may be helpful, please feel free to reply.

API_Products
Visa Developer Support Specialist

Re: Error format depending on the error type

Hey @Vito,

 

When working with the Visa Developer Platform, it’s essential to handle different error response formats gracefully, as you might encounter various error messages that do not conform strictly to the OpenAPI specification. Here’s how you can approach this:

 

General Approach to Error Handling

1. Primary Deserialization Attempt:
- First, attempt to deserialize the error response based on the OpenAPI specification provided for each service.

2. Fallback Deserialization:
- If the primary deserialization fails, implement a fallback mechanism to handle more generic error formats. This usually involves logging the raw error message and extracting key information such as HTTP status codes, error messages, and relevant metadata.

3. Logging:
- Always log the raw error response for debugging and future reference.

 

Example Strategy in Pseudocode

```python

 

# START
try:
# Attempt to deserialize based on OpenAPI spec
error_response = deserialize_to_openapi_format(response)
except DeserializationError:
log("Failed to deserialize using OpenAPI format")
# Fallback deserialization
try:
error_response = deserialize_to_generic_format(response)
except DeserializationError:
log("Failed to deserialize using generic format. Logging raw response")
log(response.raw)
# Optionally, create a generic error response object
error_response = create_generic_error_response(response.raw)
# END 
```

 

Identifying Non-MLE Services

To determine if a service is not an MLE (Mutual Link Establishment) service and thus might use a different error format:

1. Service Documentation:
- Review the service documentation on the Visa Developer Portal to understand the expected error response formats.

2. API Specifications:
- Look for any notes in the OpenAPI specifications that might indicate variations in error response formats.

3. Environment-Specific Errors:
- Some errors, like the absence of a sandbox environment, might not be documented in the API specs. These can be identified by specific HTTP status codes or error messages.

 

Example Logic for Handling Non-MLE Services

```python
# START 
def handle_api_error(response):
try:
# Attempt primary deserialization
error_response = deserialize_to_openapi_format(response)
except DeserializationError:
log("Primary deserialization failed")
if is_non_mle_service(response):
try:
# Attempt to deserialize using non-MLE format
error_response = deserialize_to_non_mle_format(response)
except DeserializationError:
log("Non-MLE deserialization failed. Logging raw response")
log(response.raw)
error_response = create_generic_error_response(response.raw)
else:
log("Unknown service type. Logging raw response")
log(response.raw)
error_response = create_generic_error_response(response.raw)

return error_response

def is_non_mle_service(response):
# Placeholder logic to determine if the service is non-MLE
return "specific-indicator" in response.headers or "specific-indicator" in response.body
# END 
```

 

- Primary Deserialization: Try deserializing based on OpenAPI specifications.
- Fallback Mechanism: Implement a fallback for generic error formats.
- Logging: Always log the raw error response.
- Non-MLE Identification: Use service documentation and specific indicators to handle non-MLE services differently.

By following this structured approach, you can handle various error response formats more robustly and ensure your application can adapt to different scenarios without failing on deserialization.

 




Thanks,

Tee



Was your question answered? Don't forget to click on "Accept as Solution" to help other devs find the answer to the same question.