В веб-службах RESTful должны ли отвечающие DTO содержать свои дочерние DTO?
Рассмотрим пользователя (/users/{id}), у которого есть имя и несколько местоположений (/users/{id}/location).
Когда я запрашиваю пользователя (/user/{id}), должен ли этот пользователь быть полностью представлен - его идентификатор, имя и местоположение - или местоположения должны возвращаться только по отдельному запросу? Например, какой JSON DTO вы ожидаете при запросе пользователя с id = 123 (/ users / 123):
1) {"id": 123, "name": "Peter", "location":[{"id":1, "name":"Chicago"}, {"id":2, "name":" Нью-Йорк"}] }
2) {"id": 123, "name": "Peter", "location": [{"id": 1}, {"id": 2}]}
3) {"id": 123, "name": "Peter", "location": [1, 2]}
4) {"id": 123, "name": "Peter"}
Является ли это более субъективным, подталкивающим и изменяющим размер DTO и запросов, требуемых в типичном сценарии использования? Я склонен просто включать все соответствующие данные (1), но я не уверен, что это лучше, чем просто требовать, чтобы разработчики сделали несколько вызовов API, чтобы получить все данные, которые им действительно нужны.
3 ответа
Чтобы быть RESTful, вам не обязательно возвращать полное представление ресурса. Однако вы хотите включить гипермедиа как средство для получения / установки всей информации, которая нужна пользователю вашего API (Hypermedia как движок состояния приложения - также как HATEOAS).)
Чтобы убедиться в этом, вы можете использовать предложение @bowmanb для установки URI для всех местоположений или добавить отдельные URI для каждого местоположения. Возможно, вы захотите добавить дополнительные URI для других вариантов действий с ресурсом.
Есть хорошая статья о HATEOAS Джима Уэббера, Саваса Парастатидиса и Яна Робинсона под названием "Как получить чашку кофе"
Я новичок в этом мире, но я создаю успокоительный API и сталкиваюсь с точно такой же проблемой. Моя первоначальная работа была направлена на включение всего, поэтому мои результаты выглядят как ваш вариант (1). Фактически, я пошел немного дальше и включил URI для каждого объекта, так что теоретически, ответ может быть перемещен достаточно интеллектуальным клиентом.
Сказав это, я обнаружил, что один конкретный атрибут моего эквивалента вашему "пользовательскому" объекту огромен. Похоже, что это не влияет на производительность, но мне кажется, что ни один клиент не захочет получить всю эту информацию об этом конкретном атрибуте - большинству клиентов просто понадобятся идентификатор и имя. Итак, я буду изменять свой подход по умолчанию для этого атрибута.
Итог - по моему мнению новичка - это то, что решение зависит от ожидаемого использования ваших клиентов - что бы клиент хотел видеть?
Должен быть какой-то способ для клиента определить, как найти местоположение пользователя. Так что я бы исключил номер 4.
Если вас беспокоит размер вашего ответа, я считаю, что было бы RESTful включить только URI для местоположений пользователя:
{ "id":123, "name":"Peter", "locations":"/users/123/locations" }