Обновить вложенный объект с помощью REST API

Question

У меня есть ресурс Student и 4 конечных точки API:

POST: /students
GET: /students/{id}
PUT: /students/{id}
DELETE: /students/{id}

Теперь я хочу добавить новое свойство Address как объект к Student:

class Student 
{
   public int Id;
   public string Name;
   public Address Address;
}

Address также имеет свойство Street как объект.

Мой вопрос: если я хочу обновить только address или street, было бы лучше:

• Использовать обновление API ученика: укажите все свойства ученика, даже если они не изменились
• Создание новых конечных точек PUT: /students/{id}/address и PUT: /students/{id}/address/street

Answer 1

Зависит от того, насколько дружелюбным клиентом вы хотите, чтобы API был. Недавно я видел API, который возвращает объект, но чтобы обновить одно поле в объекте, клиент должен вызвать другую конечную точку, чтобы получить дополнительную информацию для добавления к исходному объекту, чтобы ПОСТАВИТЬ обновленный объект. Я считаю это недружелюбным клиентом.

Если клиент GET sa Student и он получает полный объект Id, Name, Address, Street, тогда я ожидаю, что PUT: /students/{id} сможет обрабатывать полный объект, обновление полей, которые отличаются от полей в базе данных или там, где хранится объект. Если API предоставляет клиенту полный объект, то API должен быть дружественным к клиенту и иметь возможность принимать полный объект обратно, а не заставлять клиента деконструировать объект.

Я бы не ожидал, что клиенту придется извлечь Address из Student, затем извлечь Street из адреса и отправить его на PUT: /students/{id}/address/street, если API предоставил клиенту полный Student объект на первом месте.

Единственный недостаток этого подхода - пропускная способность. Если одна буква на улице изменяется, клиент должен PUT всего объекта Student. Таким образом, это действительно зависит от того, кем является клиент и в какой сети он работает. REST клиент в интернете? Принимаю полные объекты. Встроенный клиент на устройстве с ограниченными ресурсами? Может потребоваться отправить фрагменты объекта, но это приводит к тому, что конечные точки REST соответствуют иерархии объектов Student, что для меня является тесной связью и не очень рекомендуется.