Рассмотрим ресурс, на котором несколько действующих лиц могут выполнять одно и то же действие.Примером может служить ипотечный кредит, для которого и банк, и рейтинговое агентство могут одобрить или отклонить запрос на ипотечный кредит.Вот несколько вариантов структуры API:
a) Актер является частью URL
/ loan / {id} / bank / Approve
/ loan / {id} / ratingagency /Одобрить
b) Актер является частью заголовка
/ loan / {id} / Утвердить
x-actor: bank |ratingagency
Преимущества a)
1. Из журналов доступа будет легче определить действующего лица и действие
2. С точки зрения архитектуры микросервисов развертывание и масштабирование API может быть проще, еслиМасштабные требования по утверждению банка отличаются от требований рейтинговых агентств.Не уверен, что это возможно и с заголовками (?)
Преимущества b)
1. Больше в соответствии с принципами REST (?)
Любые другие?
Дляа) можно утверждать, что API с подресурсами структурированы следующим образом.Таким образом, одно и то же может быть применено к разным действующим лицам с одним и тем же действием.
Поиск предложений / мнений по поводу двух вышеупомянутых подходов.