REST вызов может привести к двум различным объектам JSON. Какую модель дизайна я должен использовать?

Мое веб-приложение делает звонок REST. Если вызов будет успешным, он вернет объект «погода» json. Если вызов завершится с ошибкой, он вернет объект ошибки json.REST вызов может привести к двум различным объектам JSON. Какую модель дизайна я должен использовать?

Я хочу создать класс, который анализирует полученный JSON и возвращает объект Weather, если вызов преуспел, и объект Error, если вызов завершился неудачно.

Я думаю об использовании шаблона Factory, но я не уверен, что это хороший подход, потому что два объекта сильно отличаются друг от друга. Каков хороший способ разработки этого кода?

источник

2013-06-04 W.K.S

Общий подход, который я использую, чтобы иметь Weather и Error оба Response объектов и имеет ResponseFactory их создание.

Я настоятельно рекомендую вам использовать надлежащие коды HTTP при разработке своего сервиса, поскольку они дают более общий обзор состояния и успеха каждого вызова.

источник

2013-06-04 15:11:19 mbanzon

Проблема в том, что объект Weather является классом Model в моем шаблоне MVC. Я думаю, что это немного грязно, если я наследую от Response. –

@ W.K.S, это, безусловно, проблема. Это проблема реализации, но в первоначальном вопросе не указано, что уже были реализации Model или Response. Некоторая работа, которую я делаю, вносит ошибки в журнал (db) - и тем самым оправдывает, что объект Error также является объектами модели. – mbanzon

Я подумываю о создании класса «WeatherException» (позже я придумаю лучшее имя), содержащего все коды ошибок и сообщения. Таким образом, 'WeatherFactory' создаст объекты« Погода », если код будет успешным, но он создаст и выбросит« WeatherException », если код не сработает. Соответствует ли это шаблону Factory? –

Это действительно зависит от среды, в которой вы будете использовать API.

Как правило, полагайтесь на код HTTP - если вы получаете 404 или 500, вы, конечно, не можете получить анализируемый ответ.

Отформатировать ответы об ошибках согласованным образом, например.

404 { "message" : "Resource not found" } 
400 { "message" : "Wrong parameters given" }

Значит, вы знаете, как их разобрать.

Если вы получаете 200 OK, вы знаете, что все было правильно, и вы можете без проблем разобрать свой ответ.

источник

2013-06-04 15:19:51 moonwave99

Вам необходимо сначала проверить результат вызова, а затем принять решение о том, как с ним обращаться, с возможностью обработки всех кодов ошибок с обратным вызовом ошибки, который возвращает объект JSON Error, а также обратный вызов успеха для вернуть объект Weather JSON. Вы можете использовать коды HTTP для создания правильного ответа и далее подразделять логику, чтобы при необходимости получать более конкретные ошибки.

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

источник

2013-06-04 15:27:48 rae1

Подходит ли заголовок Content-Type в зависимости от типа ответа?

Как некоторые отметили в своих ответах, код статуса HTTP должен использоваться для определения «Была ли ошибка», но так же важна интерпретация возвращаемого типа контента.

Надеюсь, что заголовок Content-Type будет меняться, я бы предложил использовать реестр парсеров, зарегистрированных по типу содержимого, которым они обрабатываются, а затем делегировать им обработку понимания того, как преобразовать определенный тип контента в требуемый объект. В Ruby, так как вы не указали конкретный язык:

case response.status: 
    when 200..299 
    return parsers[response.content_type].parse(response.body) 
    when 400..499 
    raise parsers[response.content_type].parse(response.body) 
    else 
    raise "Unhandled response status"

Это разделяющий две проблемы:

Определение, если произошла ошибка
парсинг типов контента в классы/типы в вашем приложении.

источник

2013-06-04 15:41:27 Pete

REST вызов может привести к двум различным объектам JSON. Какую модель дизайна я должен использовать?

ответ

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