Это RESTFul для вызова представления ресурса, который имеет вычисленное значение (ориентированный на пользовательский интерфейс, спецификация клиента c) - PullRequest
Новая
       159

Это RESTFul для вызова представления ресурса, который имеет вычисленное значение (ориентированный на пользовательский интерфейс, спецификация клиента c)

0 голосов
/ 21 июня 2020

В Pragmati c RESTFul API, я принимаю приведенный ниже ответ в качестве ответа для ресурса сотрудника

/ employee / 1 

{
  "name":"Foo",
  "dob": "2020-06-21"
}

Просто предположим, что мне нужно свойство DOB по-другому в моем пользовательском интерфейсе / Клиент, которого я не могу легко достичь в моем клиенте. Поэтому я изменил свой ответ, как мои ТРЕБОВАНИЯ КЛИЕНТА : 

{
  "name":"Foo",
  "dob": "2020-06-21",
  "dobShort": "Jun 21, 2020",
  "dobLong" : "Sunday, June 21, 2020"
}

Мое сомнение не в формате даты или настройке ответа, я хочу знать, это RESTFul для вызова ответа, который разделяет вычисленные / UI-зависимые / ориентированные на клиента значения.

Мне нужно беспокоиться о факторах клиента при разработке ответа REST. Я согласен, что формат даты может показаться глупым в серверной части. Но что, если этого трудно достичь во Front-End и это не имеет прямого отношения к каким-либо ресурсам.

Должен ли мой ответ REST заботиться о спецификациях клиента c Factors? мне не хватает хорошо известного соответствия REST?

Ответы [ 2 ]

0 голосов
/ 21 июня 2020

Я хочу знать, является ли RESTFul вызовом ответа, который разделяет вычисленные / зависимые от пользовательского интерфейса / ориентированные на клиента значения.

Да, это так.

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

REST не заботится о том, несет ли представление избыточную информацию.

Должен ли мой ответ REST учитывать параметры клиента c Факторы?

«Необходимо»? нет, это не обязательно. Кроме того, это не запрещено.

0 голосов
/ 21 июня 2020

В вашем дизайне RESTful API неразумно иметь более одного свойства в теле ответа, отображающего одни и те же данные в разном формате. Было бы разумнее позволить клиенту анализировать данные в соответствии с тем, как им нужно. В примере сценария, который вы упомянули, сервер REST может отправлять дату в формате ISO8601, а клиент должен преобразовать ее в версию, которую он хотел бы.

Однако вы можете поддерживать различные форматы контента, которые клиент может запросить через заголовки Accept (это связано с согласованием содержимого). Вы также можете разрешить разбиение на страницы, если набор результатов для вызова GET all слишком велик для обработки за один вызов. Но если есть какие-то c вычислительные требования клиента, лучше переложить эту работу на клиентскую сторону. Это может быть удобно, если в будущем на сервере RESTful будет несколько приложений, которые будут связываться с ним как с клиентами. Добавление клиентских c вещей на стороне сервера также будет способствовать тесной связи, что не может вас радовать, глядя на приложение в долгосрочной перспективе.

...