Стандарты REST. Должны ли модели вывода всегда соответствовать модели ввода?

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

Таким образом, пример модели вывода может быть:

{
  statuses : {
    enumValue1 : "Display This Text",
    enumValue2 : "Display This Text2",
  },
  thePrice : {
    value : 3.50,
    formattedValue : "$3.50"
  },
  length : {
    meters 3,
    formattedValue : "3 ft."
  },
  iAmAPropertyOnlyInGet : 42
}

Теперь, если у меня есть это как моя модель вывода, "нормально ли" иметь совершенно другую модель ввода?

{
  status : {
    enumValue1,
    enumValue2,
  },
  thePrice : 3.50,
  lengthInMeters : 3  
}

Ответ 1

Представления, отправленные на исходный сервер, могут быть совершенно разными, чем представления, которые вы получаете. Рассмотрим, как работают веб-браузеры. Вы GET text/html и вы POST application/x-www-urlencoded-form.

При использовании метода PUT это нормально для того, что вы PUT и что GET должно быть схожим, если не идентичным.

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

Таким образом, на самом деле разделение типа модели между клиентом и сервером без явного определения этого типа в сообщении является нарушением самоописательного подзадачи REST.

Ответ 2

Это зависит от того, какую гибкость вы хотите предоставить своим клиентам (потребители услуг REST).

Если вы поддерживаете ту же модель, потребитель может загрузить существующую модель, изменить значения, а затем отправить ее обратно, что очень естественно при использовании сценариев CRUD.

Однако, если вы ожидаете иметь два отдельных сценария: 1- для импорта данных и 2- для экспорта данных, возможно, они могут быть разными.

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

Ответ 3

Я бы сохранил метаинформацию в отдельном объекте, кроме самих данных.

Итак, в ответе JSON первый объект будет похож на

{ meta:  { priceformat: $, lengthformat: ft },
 thePrice: 3.50,
 length: X
}