Пользовательский интерфейс, ориентированный на задачи, и API сервера приложений Rest - PullRequest
Новая
       5

Пользовательский интерфейс, ориентированный на задачи, и API сервера приложений Rest

4 голосов
/ 22 августа 2011

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

Клиентское приложение использует REST / JSON для связи с сервером приложений.

Для части CRUD часть API REST в основном прямая. Но разработка API для задач, ориентированных на выполнение задач, в нашем приложении немного сложнее.

Как можно было бы разработать REST API, который бы отличал два разных действия с ресурсом, которые фактически просто обновляли данные?

В качестве примера. Пользователь может изменить адрес человека по следующим причинам:

  1. Адрес содержит ошибку, например, название улицы пишется неправильно.
  2. Человек переехал на другой адрес

Обе причины приводят к одной и той же конечной ситуации; данные изменились. Но в REST API должна быть какая-то разница, чтобы иметь возможность реагировать по-другому.

Ответы [ 3 ]

0 голосов
/ 28 февраля 2012

Я работал над маленькой утилитой, которая позволяет вам публиковать команды CQRS на URL RESTful. CQRS хорошо подходит для ориентированного на задачи пользовательского интерфейса. Но для нескольких проектов это понимается в сценариях управления, вы можете захотеть управлять всем объектом (например, ManagingAddress). Только не забывайте, что, изменяя свойство из всех охватывающих пользовательский интерфейс управления, вы можете случайно пропустить некоторую логику, которая захватывается более детальной командой - в вашем случае ChangingAddress).

В подобных случаях очевидно, что вы выполняете две отдельные команды (одна только более гранулированная, чем другая). Независимо от того, представляете ли вы их как два отдельных URL-адреса, остается только напоминание о том, что для любых дополнительных объектов может потребоваться аналогичный тип интерфейса CRUD и URL-адрес REST. Но в любом случае я просто встраиваю более детализированную команду в свою более сложную команду (поэтому детальные особенности подобраны в вашей более широкой и всеобъемлющей команде).

0 голосов
/ 13 ноября 2015

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

  • Исправление опечатки в адресе:

PUT / ресурс / клиент / 123 / адрес

  • Клиент перемещен, выполните изменение адреса:

POST / resource / customer / 123 / changeOfAddress

В последнем случае тело HTTP предположительно будет содержать дополнительную информацию, такую ​​как «дата вступления в силу». Кроме того, заголовок content-location, возвращаемый из вышеприведенного POST, вероятно, будет содержать URI для ресурса, который показывает старый адрес, новый адрес и когда произошел переход.

Таким образом, changeOfAddress номинально является «процессом», но практически сам по себе является существительным; из модели POV, это первоклассный гражданин.

0 голосов
/ 23 августа 2011

Если вам нужны разные методы «обновления», я бы просто включил в название что-то описательное (например, /Address/UpdateStreetName). Вы можете включить метод "/ Update", но в отличие от более конкретных имен, которые могут выглядеть немного двусмысленно.

Кроме того, сосредоточен ли API на данных или сценариях потенциальных пользователей? Лично я бы построил свой API на основе данных - но убедился, что он охватывает все вероятные сценарии. Например, обновление названия улицы по отдельности может иметь смысл (исходя из того, что оно может быть неправильно написано), но означает ли это автоматически, что вы хотите предлагать возможность обновления для каждого другого поля в отдельности? Может быть, а может и нет.

Чтобы быть уверенным - хороший API позволит пользователям эффективно работать и охватывать все / большинство сценариев (% 80>) без лишних хлопот, но если принять ориентированный на данные подход в качестве приблизительного ориентира, вы будете меньше может дублировать без необходимости. Например, будет несколько причин для изменения адреса (не все могут быть известны во время разработки), переход на другой адрес только один, но общий эффект будет таким же (так как изменяются те же данные).

...