То же конечная точка REST, возвращающая различные объекты ответа на ошибку

Question

Приложение My Client является потребителем конечной точки REST, производящей ответы JSON, которые могут возвращать ответы об ошибках, имеющие разные структуры для разных сценариев;

Ошибка 1

{ 
    "errorCode" : "XXXX" 
    "errorMessage" : "Validation Failed" 
}//Note the lack of higher order key here; it's flat 

Ошибка 2

{ 
    "apiError" : { 
    "errorCode" : "XXXX" 
    "errorMessage" : "Validation Failed" 
    } 
}//Note "apiError" is an object 

Ошибка 3

{ 
    "apiError" : [{ 
    "errorCode" : "XXXX" 
    "errorMessage" : "Validation Failed" 
    }] 
}//Note "apiError" is a Collection 

Как мы видим выше немногие из ответы об ошибках имеют один и тот же ключ, но с разными типами возврата;

«errorCode» встроен в разные ключи и также не отображается глобально на одном уровне с помощью JSON Response.

Я немного не знаю, как подойти к этому сценарию? Есть ли какой-либо шаблон дизайна или какая-либо работа вокруг него?

Некоторые рекомендации приветствуются.

Answer 1

При проектировании надежного API вам необходимо использовать коды состояния http. Соответствующая информация об этом link.

Примеры ответов следующие.

Сценарий успеха (один или несколько сценариев);

{ 
    "errors": null, 
    "results": [{ 
     "key": "value" 
    }] 
} 

Сценарий ошибок;

{ 
    "errors": [{ 
     "code": "ERR-500", 
     "message": "Error text" 
    }], 
    "results": null 
} 

Сценарий множественной ошибки;

{ 
    "errors": [{ 
     "code": "ERR-500", 
     "message": "Error text" 
    },{ 
     "code": "ERR-403", 
     "message": "Error2 text" 
    }], 
    "results": null 
} 

Answer 2

Там нет «стандартного» способа справиться с этим, но, как правило, что вы должны делать в этом случае читается в документации по API.

Хороший API, вероятно, использует один и тот же формат json для каждого типа ошибок, но если они этого не делают, они должны хотя бы документировать его. Хороший API, вероятно, также использует разные типы медиа для каждого типа ошибок (поэтому вы можете проверить Content-Type, чтобы выяснить, как разбирать сообщение об ошибке).

Возможно, документы API при выходе каждого типа ошибки. Но если ни один из них не поможет вам лучше справиться с этими типами ошибок в общем виде, вам просто нужно будет взглянуть на тело ответа и решить, как его разобрать, исходя из того, что вам было дано.