2016-08-02 1 views
0

Я работаю с новой системой и создаю контракты с ошибками, которые я собираюсь вернуть. Я пытаюсь следовать за OData v4 Error Response structure.Может объекты OData Error содержать произвольные свойства

Поскольку это служба C#, похоже, что существует очень хорошее сопоставление между объектами исключений и OData Error Response. Однако мы пытаемся определить, нормально ли для объекта «Ответ на ошибку» содержать дополнительные произвольные свойства. Внутренние ошибки явно указаны, как будет разрешено иметь дополнительные свойства, поэтому справедливо следующее:

{ 
    "error": { 
    "code": "BadArgument", 
    "message": "Previous passwords may not be reused", 
    "target": "password", 
    "innererror": { 
     "code": "PasswordDoesNotMeetPolicy", 
     "minLength": "6", 
     "maxLength": "64", 
     "minDistinctCharacterTypes": "2", 
    } 
    } 
} 

Data собственности на исключении карты очень хорошо к этому, и мы можем просто преобразовать каждое значение на внутреннем исключении в свойство ошибки. Таким образом, если клиент добавляет произвольные свойства к внешнему исключению, можно ли выставлять их как свойства в корне. Например:

{ 
    "error": { 
    "code": "BadArgument", 
    "message": "PasswordDoesNotMeetPolicy", 
    "target": "password", 
    "minLength": "6", 
    "maxLength": "64", 
    "minDistinctCharacterTypes": "2", 
    } 
} 

Или что-то подобное в целом считается «плохой формой» для OData?

ответ

0

Если вы добавляете пользовательские свойства непосредственно на объект error, вы получите нестандартный ответ об ошибке. Инструменты генерации кода и сторонние клиенты не будут распознавать пользовательские свойства.

Недвижимость innererror является дополнительной точкой. spec says: «Содержимое этого объекта определено по умолчанию. Обычно этот объект содержит информацию, которая поможет отладить службу». Stick с innererror.