2017-02-21 2 views
1

Так, по данным официальной выборки документации, ответы от OneNote может иметь следующую структуру:Есть ли способ использовать универсальный базовый отклик, содержащий поля значений, ошибок и предупреждений?

{ 
    value:{the content we requested}, 
    error:{error if exists with warnings inside if exist}, 
    @api.diagnostics:{warnings if exist} 
} 

Но, если тело ответа содержит не массив JSON, но JSON объект, то ответ будет следующим

{ 
    Here would be entity, representing the content we requested 
} 

Итак, мой вопрос следующий: есть ли способ унифицировать ответы от OneNote API, поскольку существующая структура ответа нарушает его контракт.

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

ответ

0

http://www.odata.org/getting-started/basic-tutorial/

OneNote API, является OData API - это значит, что соответствует стандарту OData, где массивы возвращаются как часть имущества стоимости.

В то время как объекты в массивах возвращаются в свойстве «значение»:

{ value:[element1, element2, ...], }

И конкретные лица не являются

{ element1 }

Это относительно легко решить на любом языке , который поддерживает дженерики с использованием класса контейнера для полезных данных odata, например:

class ODataPayload<T>{ Public IList<T> Values {get; set;} }

Таким образом, вы можете разобрать «T» при получении одного объекта и ODataPayload при получении нескольких.

Или вы также можете использовать что-то вроде http://json2csharp.com/, чтобы сгенерировать классы разбора.

Обратите внимание, что ошибки будут возвращены только с кодами статуса 4xx ad 5xx. Любой код состояния 2xx должен предоставить вам сущность.

+0

Спасибо за ответ, но что вы сказали, что я сказал, что я знаю. Вопрос заключался в следующем: как отделять ошибки и предупреждения от данных ответа (фактические данные, которые мы хотели получить). На данный момент я использую Google Gson для настройки процесса десериализации как низкоуровневого перехватчика в моей модели анализа ответов. Итак, там, я выполняю перемещение дополнительных полей внутри корневого json, кроме «error» и «@api.«Диагностика», если «значение» не существует для нового элемента в корне, называемом «значение», поэтому ответ от api не отличается в зависимости от типа данных ответа. Но это действительно грязное обходное решение –

+0

Будучи более конкретным: объект никогда не должен содержать ошибку , поскольку ошибка никогда не должна содержать объект. Это архитектурная ошибка. Как будто мы говорим в терминах чистой архитектуры - уровень сущности должен содержать универсальный формат ответа, который ВКЛЮЧАЕТ как данные ответа свойств, описание ошибки, если существует, и другие специальные поля, это будет общим для КАЖДОГО ответа. В противном случае существует вероятность недоразумения, когда объект будет содержать какое-либо поле с именем, равным общей ошибке части ответа (например, объект, содержащий опору «ошибка» и общий ответ, содержащий опору «ошибка») –

+0

Обновлен мой ответ. Ошибки будут возвращаться только в коды состояния 4xx и 5xx, объекты будут возвращаться только в кодах состояния 2xx. –

1

Фактически, нет способа, кроме одного грязного обходного пути, упомянутого выше. Чтобы реорганизовать API OneNote (и другие общие службы), необходимо реализовать либо перехватчик, либо что-то вроде сервлета, который перенесет все неизвестные свойства, которые, похоже, являются свойствами entitiy для нового свойства root json, что делает его похожим на формат ответ для коллективного представления данных. Итак, если API не будет реорганизован в соответствии с хороший стиль ничего не поделаешь. Надеюсь, что кто-то из Microsoft увидит это и оставить комментарий о том, почему реализация API является требует стороне сервера работа на клиенте

Смежные вопросы