При проектировании RESTful API должны ли ресурсы, зависящие от других, моделироваться как суб-урис или они должны просто ссылаться друг на друга?
например. предполагая, что дверь всегда зависит от дома, тогда
/house/73/door/1
или
/house/73
/door/1044
где дом и дверь включают ссылки друг на друга?
Большинство API-интерфейсов RESTful, которые я нашел, довольно плоские, поэтому я бы оценил ссылки на любые, у которых есть более сложные зависимости отношений.
Привет
В терминах UML, если это отношение относится к агрегированию, вы используете плоскую иерархию со связями между вещами, тогда как если отношение является отношением к композиции (т.е. время жизни door строго ограничено временем жизни из house) вы используете субресурсы.
Я не предлагаю рисовать диаграмму UML! Но это помогает иметь в виду это различие. (Вы также можете моделировать случай агрегации, имея подресурсы, которые просто перенаправляются на реальные, перенаправления RESTful. OTOH, мне не нравится это делать, я предпочитаю делать какие-либо отношения явным и поддерживать количество перенаправляет вниз.)
Просто помните, что URI являются детальностью реализации сервера. Если вы можете моделировать их как плоские ресурсы, тогда сделайте это. Сервер будет проще обрабатывать их.
Если идентификатор двери не является уникальным для всех домов, то вашему серверу нужно будет знать дом, и поэтому вам нужно включить дом в URI.
Отношения между ресурсами должны быть смоделированы по ссылкам в возвращаемых представлениях. т.е. ваше представление о доме должно, вероятно, содержать ссылки на все дверные ресурсы в этом доме. Я бы рекомендовал попытаться избежать использования структуры URL как имеющей некоторый смысл домена.
Используйте только иерархию, если требуется уникальная идентификация ресурса.