Я работаю над дизайном RESTFul API, и меня смущает следующий вариант использования:
У меня есть пользователи и ссуды, где пользователи берут ссуду. API необходимы для а) Управление пользователями б) Получить информацию о кредите выбранного пользователя.
Вариант использования а) довольно прост. Конечная точка будет GET / api / users / для получения информации о пользователе. Как создать конечную точку API для получения информации о загрузке пользователя:
GET /api/loans/<user unique id>/
or
GET /api/users/<user unique id>/loans
Обратите внимание, что они отличаются от того, что оба они используются для однозначной идентификации пользователя.
Мы ценим любые предложения.
Спасибо,
Радж
REST не заботится о том, какое написание вы используете для идентификаторов ресурсов.
Следовательно, написание идентификаторов во многом похоже на написание имен переменных; выбор вариантов написания, соответствующих местным правилам, - хорошая идея.
Спецификация URI отличает иерархическая информация от неиерархической информации. Можно было бы разумно возразить, что «ссудный сбор Боба» иерархически подчинен «Бобу», и что написание идентификаторов должно отражать это
/api/users/12345
/api/users/12345/loans
Дополнительным преимуществом этого написания является то, что ссылка на другие ресурсы, подчиненные Бобу, тривиальна благодаря относительные ссылки
uri(/api/users/12345/addresses) === uri(/api/users/12345/loans).resolve(../addresses)
Однако это не влияет на отношения между ресурсами. Например, успешный небезопасный запрос к /api/users/12345
приведет к тому, что аннулировать ранее кэшировал представления этого ресурса, но это никак не повлияет на /api/users/12345/loans
.
Например:
GET /api/users/12345/loans
DELETE /api/users/12345
Что касается клиента, сходство в написании идентификаторов не подразумевает каких-либо особых отношений между этими двумя ресурсами; представление ресурса loans
в кэше будет по-прежнему считаться действительным, даже если пользовательский ресурс был удален.