Могу ли я добавить дополнительные поля в vnd.error? - PullRequest
Новая
       26

Могу ли я добавить дополнительные поля в vnd.error?

0 голосов
/ 20 июня 2019

В Spring HATEOAS вы можете вернуть VndError объект, который выглядит следующим образом: 

[
  {
    "logref" : "some request id",
    "message" : "your request was incorrect."
  }
]

В спецификации mime-типа упоминаются некоторые необязательные и обязательные поля, но он не говорито добавлении дополнительных полей.

Если бы я расширил полезную нагрузку vnd.error, чтобы она выглядела следующим образом: 

[
  {
    "logref" : "some request id",
    "message" : "your request was incorrect.",
    "additional" : {
      "some" : "additional",
      "payload" : "fields"
    }
  }
]

Формат все еще действителен в соответствии со спецификацией?

1 Ответ

1 голос
/ 20 июня 2019

Нет упоминания об эквиваленте xsd:any (задокументировано здесь ). то есть не существует способа расширить схему. Если вы управляете только одним клиентом, вы можете «раскошелиться» на схему и добавить дополнительные вещи, о которых клиент будет знать, что они существуют. Однако, если любой клиент может получить к нему доступ и ожидает vnd.error, что он и ожидает, если видит application/vnd.error+json и если он не игнорирует неизвестные атрибуты в своем анализаторе, он может не выполнить синтаксический анализ и даже не получить ошибку. .

Плюс, если клиент не заботится об ошибке, а хочет вместо него заголовок Retry-After, запрос будет содержать ненужные данные.

Можете ли вы создать новую конечную точку /logref/, возможно? Клиент может отправить vnd.error logRef и получить больше информации, и вы можете отправить в него все, что вам нужно, поскольку это не будет vnd.error ответом.

В конечном счете, logRef для серверной части. Любой клиент будет заинтересован только в том, чтобы показать сообщение его пользователю и logRef, если он захочет отследить ошибку, но я подозреваю, что ошибка ThreadLocal может не иметь никакого смысла для клиента. Содержимое, на которое указывает logRef, будет иметь смысл только для сервера.

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

...