Моделирование отношений ресурсов с RESTful API - PullRequest
15 голосов
/ 24 сентября 2010

При разработке RESTful API следует ли моделировать ресурсы, которые зависят от других, как подуровни или они просто ссылаются друг на друга?

например. если предположить, что дверь всегда зависит от дома, то

/house/73/door/1

или

/house/73
/door/1044

где дом и дверь содержат ссылки друг на друга?

Большинство обнаруженных мной API-интерфейсов RESTful довольно плоские, поэтому я бы оценил ссылки на любые, которые имеют более сложные зависимости отношений.

Привет

Ответы [ 2 ]

13 голосов
/ 24 сентября 2010

В терминах UML, если отношение является отношением агрегации, тогда вы используете плоскую иерархию со связями между вещами, тогда как если отношение является отношением композиции (т. Е. Время жизни door строго ограничено временем жизни house) вы используете подресурсы.

Я не предлагаю рисовать UML-диаграмму! Но это помогает иметь в виду это различие. (Вы также можете смоделировать случай агрегации, имея подресурсы, которые просто перенаправляют на реальные; перенаправления являются RESTful. ОТО, на самом деле мне не нравится это делать; я предпочитаю делать любые отношения явными и уменьшить количество переадресаций.)

13 голосов
/ 24 сентября 2010

Просто помните, что URI являются подробностями реализации сервера. Если вы можете смоделировать их как плоские ресурсы, сделайте это. Серверу будет легче с ними справиться.

Если идентификатор двери не является уникальным для всех домов, то вашему серверу потребуется знать дом, и поэтому вам необходимо включить дом в URI.

Отношения между ресурсами должны моделироваться ссылками в возвращаемых представлениях. Т.е. ваше представительство в доме, вероятно, должно содержать ссылки на все дверные ресурсы в этом доме. Я бы порекомендовал стараться избегать использования структуры URL как имеющей некоторый смысл в домене.

Используйте иерархию, только если она необходима для однозначной идентификации ресурса.

...