В API, который я собираю, я выполняю команду Действие по набору объектов. Проблема, с которой я сталкиваюсь, заключается в том, как разрешить действие изменять в зависимости от предпочтений клиента и поддерживаемых методов.REST API Design - подтипы ресурса ресурсов
Некоторым типам действий потребуется клиент для предоставления дополнительных параметров: например, одно из действий приведет к отправке отправленного сообщения, поэтому клиенту необходимо предоставить тело, получателей и т. Д. Сервер может знать о больше типов действий, чем клиент делает. Например, можно добавить новый метод отправки, но старый клиент не будет знать, как настроить параметры для него. Кроме того, существуют типы действий, которые не требуют никаких параметров от клиента, и, следовательно, все клиенты могут использовать это, как только сервер будет включен для него.
Как и различные типы действий, основанные на тех, которые поддерживаются клиентом/сервером, выбранные сущности также имеют эффект - некоторые объекты недействительны для некоторых типов действий.
В конце этого согласования клиент (в конечном счете, конечный пользователь) может свободно выбирать любые типы действий «без опции», применимые к этим объектам, или любые типы действий «необходимости» применимые к этим объектам и поддерживаемые как клиентом, так и сервером.
Действия запускаются путем установки поля состояния на committed или аналогичного.
Мои мысли до сих пор состоят в том, чтобы предоставить общий ресурс DoAction с подсерией объектов. Свойство на этом ресурсе позволяет указать «ActionType». Затем есть еще один подресурс, называемый ActionOptions, и это означает, что вы либо задаете параметры для конкретного типа, который используете, либо оставляете его пустым для типов «без опции».
Проблема, с которой я столкнулась, заключается в том, чтобы решить, является ли это наилучшим подходом, или если что-то, что связано с типами контента, будет лучше, а также как согласовать список доступных типов действий для клиента, в том числе без опции типы, которые клиент может поддерживать, даже если он явно не знает об этом.