Я думаю, что это скорее пользовательский интерфейс, чем API-объект, то есть пользовательский интерфейс должен предварительно заполнять значения по умолчанию в соответствующие поля формы для пользователя, которые затем просто заполнят пробелы и настраивают по умолчанию если необходимо. Это не применимо везде (например, когда у вас есть только API без бита пользовательского интерфейса).
Вы уже предложили некоторые варианты самостоятельно - они будут работать, однако при условии, что вы можете получить доступ к существующим ресурсам, как /resource/123
, оба варианта сломают ваш дизайн URI хотя бы немного. Я могу думать о трех альтернативах того, как подойти к этому, последний (третий) вариант может быть лучшим выбором.
Подход № 1
Лучше подход может имитировать способ, как время-ресурсоемких задач, как правило, делается в REST. Обычно у вас есть ресурс, к которому вы отправляете задание, затем служба отвечает на URI задачи, который позже можно использовать для проверки выполнения задачи. Мы можем адаптировать его к нашему случаю - определить пустые ресурсы со значениями по умолчанию в качестве нового ресурса, которые мы можем использовать для получения «шаблона» для другого ресурса.
Пример:
Предполагая, что вы хотите получить шаблон для ресурса под названием «пользователь». Вы бы сначала сделать запрос POST для шаблона ресурса и указать тип ресурса, для которого вы хотите создать «шаблон»:
POST /template/
<?xml version="1.0" encoding="UTF-8" ?>
<template>
<type>user</type>
</template>
API-интерфейс будет создавать новый «по умолчанию» ресурс для указанного типа , в случае успеха он ответит бы с:
HTTP/1.1 204 No Content
Location /user/123
место указано в ответе вашего API, будет содержать шаблон для ресурса:
GET /user/123
<?xml version="1.0" encoding="UTF-8" ?>
<user>
<id>123</id>
<name />
<email />
<preferred-language>en</preferred-language>
<timezone>UTC</timezone>
...
</user>
Подход №2
Подход №1 уже создает для вас ресурс. Альтернативный подход - предоставить пользователям доступ к шаблонам для получения определенного URI.
Пример:
GET /template/user
<?xml version="1.0" encoding="UTF-8" ?>
<user>
<name />
<email />
<preferred-language>en</preferred-language>
<timezone>UTC</timezone>
...
</user>
Подход № 3
Существует еще одна альтернатива - я считаю, что это самый простой и логичный подход, но он может не подходить для всех случаев. Вы можете создать пустой ресурс с настройками по умолчанию, выполнив запрос POST непосредственно к ресурсу, с которым вы хотите работать.Одним из недостатков может быть то, что это не позволит пользователям просто просматривать шаблон (который они могли бы использовать в подходе № 1), он всегда будет создавать для них ресурс (аналогично подходу № 1).
Пример:
Для того, чтобы получить версию по умолчанию ресурса вы бы отправить запрос пустой POST к этому ресурсу:
POST /user/
API-интерфейс позволит создать новый ресурс со значениями по умолчанию и отвечать с:
HTTP/1.1 204 No Content
Location /user/123
же, как и в подходе # 1, URI позволит пользователю получать созданный ресурс, а затем изменить его по мере необходимости (через PUT):
GET /user/123
<?xml version="1.0" encoding="UTF-8" ?>
<user>
<id>123</id>
<name />
<email />
<preferred-language>en</preferred-language>
<timezone>UTC</timezone>
...
</user>
Спасибо за подробный ответ. Идея с ресурсом по умолчанию заключалась в том, что я прошу его - в моем случае - иметь возможность формулировать форму пользовательского интерфейса. Поэтому создание нового ресурса может быть затруднено, если пользователь решит никогда не отправлять эту форму (что должно быть эквивалентно не созданию ресурса вообще). – Daff
@Daff: Я вижу, так что это ударяет подходы № 1 и № 3. Решения, которые я делал в прошлом, предоставляли значения по умолчанию как часть логики пользовательского интерфейса, но это не идеально, особенно если вы хотите полностью отделить пользовательский интерфейс от API. Второй подход будет работать в этом случае, я думаю, что это немного больше RESTful, чем использование '/ resource/_new', поскольку сам шаблон также является ресурсом. Однако, определяя его как новый ресурс, вы отделяете его от исходного (которому он служит в качестве шаблона), что может быть не всегда желательно (например, с точки зрения структуры URI). – MicE