Format for exceptions and errors from Yodlee REST Aggregation API - yodlee

What is the best way to catch exceptions in the response payload for API calls made to the Yodlee REST Aggregation API?
Historically speaking I've seen {'Error' => [{'errorDetail' => 'some error message'}]}, but I've also seen {'errorOccured' => true, 'exceptionType' => 'some documented exception type', 'referenceCode' => ''}.
The documentation suggests I can expect exceptionType, but I'd like to be sure. The API call I'm currently most concerned with is /login.

Here are types of error code format which you can expect-
JSON exception format 1:
{
"errorOccurred": "true",
"exceptionType": "com.yodlee.core.SiteNotFoundException",
"referenceCode": "_afe4ae60-68fe-4443-a721-d97a192e9455",
"message": "Argument value not found: 164413432"
}
JSON exception format 2 (Same as format 1, but "message" attribute is missing so considered as additional):
{
"errorOccurred": "true",
"exceptionType": "Exception Occurred",
"referenceCode": "_5c4d1347-cb4a-4404-809b-57dbfabcf1db"
}
JSON exception format 3:
{
"Error": [
{
"errorDetail": "No session ID found "
}
]
}
JSON exception format 4 (Same as format 3, but "errorDetail" attribute is missing so considered as additional):
{
"Error": [
null
]
}
JSON exception format 5:
{
"errorDetail": "Token authentication failed for cobrand/user Invalid cobrand conversation credentials"
}
This will cover almost all the scenarios.

Related

How to send multiple Validation Errors to React using Flask and Marshmallow in Backend and Axios for React-Native in Frontend

I am using Marshmallow to validate incoming fields for a simple put request.
Now I am testing the error handling in the frontend to make sure I send the right error messages for the frontend.
I am usually sending data of type
{
password: string,
email: string
}
For now Marshmallow checks if the password is long enough and if the email is of format Email.
I collect all errors in a expect statement and send it to the frontend like this:
except ValidationError as err:
return make_response(
{"errors": err.messages}, status.HTTP_400_BAD_REQUEST
)
with Postman giving me e.g. this response:
{
"errors": {
"email": [
"Missing data for required field."
],
"password": [
"Missing data for required field."
],
}
}
All error messages are therefore collected within the field errors and sent back to the frontend.
When the error is sent back to the frontend I catch my error and all I get is this object:
Object {
"data": null,
"error": [Error: Request failed with status code 400],
}
How do I correctly send or receive the
errors: err.messages
field in the frontend within a make_response error response?
I found the solution to the problem I had here:
github.com/axios/axios/issues/960.
Apparently you have to access the response object or the error object that is send to axios. There is no interceptor needed. What I changed was this line, when resolving the promise to:
try {
resolved.data = await promise;
} catch (e) {
resolved.error = e.response.data;
}
before that I accessed the error with:
try {
resolved.data = await promise;
} catch (e) {
resolved.error = e;
}
The errors are stored within the response.data.

mail.send is not accepting HTML/ CSS code

I have copied the (HTML) source code from a received email just to have the template/format of that email, and this is the error message that I am receiveing when running the API:
Internal : Unexpected error Error during Web API HTTP Request
HTTP Status Code: 400
HTTP Response Content: {
"error": {
"code": "BadRequest",
"message": "Unable to read JSON request payload. Please ensure Content-Type header is set and payload is of valid JSON format.",
"innerError": {
"date": "2020-12-02T17:01:05",
"request-id": "3ab50fc1-0c13-4536-96db-bf6b9b7a736d",
"client-request-id": "3ab50fc1-0c13-4536-96db-bf6b9b7a736d"
}
}
}
I have tested basic commands using HTML such as making text bold and line breaks which work, but anything more complex and I will receive an error.
Update**
Thank you for your response guys, the call that I'm using looks like this:
{
"message": {
"subject": "[Subject]",
"body": {
"contentType": "HTML",
"content": "[Email Body Content]"
},
"toRecipients": [
{
"emailAddress": {
"address": "[Email Address]"
}
}
],
"internetMessageHeaders":[
{
"name":"x-custom-header-group-name",
"value":"Nevada"
},
{
"name":"x-custom-header-group-id",
"value":"NV001"
}
]
}
}
**Another update ** Upon changing the content type to text/html is recieved this error:
Internal : Unexpected error Error during Web API HTTP Request
HTTP Status Code: 415
HTTP Response Content: {"error":{"code":"RequestBodyRead","message":"A supported MIME type could not be found that matches the content type of the response. None of the supported type(s) 'Microsoft.OData.ODataMediaType, Microsoft.OData.ODataMediaTyp...' matches the content type 'text/plain; charset=utf-8'."}}
note i also have tried text/plain as the content type.
Thank you
Ok, I tried the above payload (just updated the email address) and tested with Microsoft Graph Explorer. It works for me :)
Here's the payload:
{"message":{"subject":"[Subject]","body":{"contentType":"HTML","content":"[Email Body Content]"},"toRecipients":[{"emailAddress":{"address":"test#domain.onmicrosoft.com"}}],"internetMessageHeaders":[{"name":"x-custom-header-group-name","value":"Nevada"},{"name":"x-custom-header-group-id","value":"NV001"}]}}
Here's the snapshot:

Return less information for JSON parser errors

Using asp.net core 3.1 for a web api, my problem is that when a request comes in with some invalid parameters, the framework produces an error message that I don't want returned in the response.
{
"type": "https://tools.ietf.org/html/rfc7231#section-6.5.1",
"title": "One or more validation errors occurred.",
"status": 400,
"traceId": "|968ad6dd-4488d8bc10ec5760.",
"errors": {
"$.value": [
"The JSON value could not be converted to System.String. Path: $.value | LineNumber: 1 | BytePositionInLine: 15."
]
}
}
Is it possible to change this error response to something else? Ideally, I'd want to reduce the verbosity and not return the error message ("The JSON value could not be converted to System.String").
app.UseExceptionHandler does not work. ExceptionMiddleware does not work because await _next(httpContext); does not throw an exception.
Thank you in advance.
It seems that one possible way is to play with this: https://github.com/dotnet/aspnetcore/blob/5ff9ed68d1cf6c89d72d27a69b00ed0ecd34daed/src/Mvc/Mvc.Core/src/Infrastructure/ModelStateInvalidFilter.cs
Either set _apiBehaviorOptions.SuppressModelStateInvalidFilter or create a custom InvalidModelStateResponseFactory. Haven't tried it yet, but seems like a potential solution.

Getting 400 Bad Request Error for MSGraph's create subscription api [Error Code - ExtensionError]

Trying to create a subscription to get a channel for msgraph one drive notifications for file creation/upload.
I am hitting the URL -
https://graph.microsoft.com/v1.0/subscriptions
with proper headers and the following body -
{
"changeType": "updated",
"notificationUrl": "https://xxxxx.xxxxxxxxx.com/zzzz/qwertqwert",
"resource": "/users/{user-id}/drive/root",
"expirationDateTime": "2017-02-18T19:49:40.000Z",
"clientState": "justsomerandomstring"
}
I am getting the following response :
400 Bad Request Error
{
"error": {
"code": "ExtensionError",
"message": "Operation: Create; Exception: [Status Code: BadRequest; Reason: Bad Request]",
"innerError": {
"request-id": "2862896286-5415-4921-gbn5-8741288985",
"date": "2017-02-17T17:30:22"
}
}
}
I was making the same request 30-32 hrs back. Was getting the subscription-id as well as the file notifications on my redirection servlet.
Not able to figure out what changed. Couldn't find any helping documentation either
Got the same error here and it took me a while to find out what is the problem so I share this with you here.
Here's the working code:
$subscription = new Subscription([
'resource' => "me/mailFolders('Inbox')/messages?filter=id eq %27" . $draftEmail->getId() . '%27',
'notificationUrl' => 'https://my.domain.fr',
'changeType' => 'updated',
'expirationDateTime' => date(DATE_ISO8601, strtotime('+48 hours'))
]);
The line which was wrong for me is:
'resource' => 'me/messages/' . $draftEmail->getParentFolderId(),
And i replace it with
'resource' => "me/mailFolders('Inbox')/messages?filter=id eq %27" . $draftEmail->getId() . '%27',
I found my answer in this link: https://msdn.microsoft.com/en-us/office/office365/api/notify-rest-operations#subscribe-to-changes-in-my-mail-calendar-contacts-or-tasks
But in my opinion the "resource" parameter should be more documented on graph api documentation and the error message return must specify WHY this is a BadRequest.
Using beta api version solved my problem,
https://graph.microsoft.com/beta/subscriptions

JSON RPC 2.0 standard responses

I am currently looking into implementing some JSON RPC 2.0 responses in my code. However, I'm a little unclear on what are the standard practices of using it:
1) When the user sends a request with invalid parameters, should I just return verbatim default error message
{"jsonrpc": "2.0", "error": {"code": -32602, "message": " Invalid params"}, "id": "1"}
Or can the message be more specific, like:
{"jsonrpc": "2.0", "error": {"code": -32602, "message": " Invalid params: invalid username"}, "id": "1"}
Or should such custom messages have their own error code?
2) If the user say, requests data from the database and the response is "data is not present", as in we encountered no errors but still didn't return anything, should that be returned as a JSON RPC error, or should it be more of response indicating data wasn't found? In other words, is the convention in JSON RPC to use errors as normal return conditions like in Google Go, or is it more akin to "something really messed up" panics?
According to the specification (http://www.jsonrpc.org/specification#error_object) you must use the optional property data for your additional information about the error, so, in your case the response must be:
{"jsonrpc": "2.0", "error": {"code": -32602, "message": " Invalid params", "data":"invalid username"}, "id": "1"}
You can create your own personal error codes in the range -32000 to -32099, but I would do it only when necessary, that is, unless your client application should behave in this case ("invalid username") different than in any other -32602 case.
That is up to you. It is a design question with a broader scope than JSON-RCP. You can find some opinions at this post: when-to-throw-an-exception