Организационный ресурс (URI) в REST API

Question

Сценарий 1 В моем веб-приложении, скажем, есть экран для добавления сотрудника в систему.Как только пользователь вкладки после ввода имени сотрудника, он генерирует код сотрудника автоматически (который является следующим полем) на основе некоторой логики и уже присутствующих записей в базе данных.

Теперь я хочу выставить остальные APIдля этого приложения, чтобы сторонние разработчики могли строить поверх него.Итак, у меня будет ресурс под названием /Employee, который будет отвечать за глаголы GET, PUT и DELETE.Но когда клиенту нужно автоматически заполнить код, который является операцией GET, он будет на каком ресурсе?Должен ли я сделать новый ресурс /EmployeeCodeFor/{Name} или я должен получить его на /Employee/{Name}/GenerateCode?Если я выберу /Employee/{Name}/GenerateCode, то как насчет моего ресурса GET, PUT и DELETE для Employee, то есть фактически /Employee/{Id}?

Сценарий 2 Здесь давайте возьмем случай с сообщением stackoverflow.Допустим, ресурс будет /Post/{Id}.Так же, как и в предыдущем примере, он перечисляет мне возможный дубликат вопроса, как только я выхожу из поля Title.

Опять же, по какому URL я должен получить эти возможные дубликаты?

Сейчас я не могу придумать больше сценариев.Но многие подобные сценарии могут возникнуть в реальной разработке приложений.Как реализовать их в режиме RESTful?

Обновление по сценарию 1 Код и идентификатор - это два разных поля.Идентификатор является первичным ключом, код может дублироваться в разных отделах просто для иллюстрации.Кроме того, для создания кода, имя должно быть предоставлено в первую очередь.Таким образом, если пользователь вводит имя «FirstName LastName», то сервер может генерировать FL003 в виде кода, предполагая, что в указанном отделе уже есть еще два сотрудника с именем, начинающимся с F, и фамилией, начинающейся с L.Отдел можно определить по зарегистрированному пользователю.

Answer 1

Один из способов предоставить серверу возможность предварительно заполнить группу элементов в новом ресурсе - это сделать

POST /Employees
{with empty body}
=>
201 Created
Location: http://example.org/employee/3443

<Employee Id="3443">
   <Code>E1001</Code>
   <FirstName></FirstName>
   <LastName></LastName>
</Employee>

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

Answer 2

Сценарий 1

Допустим, ваш код сотрудника является уникальным идентификатором.В этом случае, чтобы получить его, вы позволите пользователю заполнить любое поле для нового сотрудника, а затем сделаете POST.Сервер сгенерирует код и ответит на POST со ссылкой на /Employee/{generated_code}, которая является записью для вашего вновь созданного сотрудника.

GET для /Employee вернет список всех сотрудников.GET на /Employee/{a_code} предоставит вам детали сотрудника.

Сценарий 2

У вас может быть какой-то запрос к коллекции /Post, например /Post?title_like={question_title},A GET /Post?title_like=REST How to вернет вам список всех вопросов, содержащих «REST How to».