Я думаю, что теоретически результат этого запроса даже не является ресурсом в терминах REST.
Это .
Ключевая абстракция информации в REST - это ресурс.Любая информация, которая может быть названа, может быть ресурсом
В REST URI является просто идентификатором для ресурса.Если мы хотим получить, например, привилегии Acme Corporation, этот URI является совершенно «спокойным»
/7B7F1B30-7A84-4406-8D88-FAC9B647AC12
Правописание не имеет значения для REST.
Ваша структура реализации,и вы, пользователи API, можете предпочесть взломанный URI ;но это не ограничение REST.
Более того, нет ограничения REST, которое требовало бы, чтобы у каждого объекта в вашей доменной модели был один и ровно один URI.«Ваша модель ресурсов - это НЕ модель вашего домена».
Короче говоря, если у вас есть одна конечная точка, которая создает представление этого результата запроса, и вам необходимо закодировать в идентификатор идентификатор компании, чтобы выполнить поиск, тогда это все отлично .
/7B7F1B30-7A84-4406-8D88-FAC9B647AC12/{companyId}
/7B7F1B30-7A84-4406-8D88-FAC9B647AC12?{companyId}
/{companyId}/7B7F1B30-7A84-4406-8D88-FAC9B647AC12
/7B7F1B30-7A84-4406-8D88-FAC9B647AC12;{companyId}
Трудная часть пытается выбрать семантически значимое / узнаваемое написание;По сути, это та же проблема, что и у вас, когда вы пытаетесь назвать переменную в вашем коде, и на вас распространяются аналогичные ограничения - то есть: компилятор не заботится , вы пишете, чтобы четко общаться с другими людьми.
Вы можете обратиться к варианту использования, который вы поддерживаете, для идей по написанию, но вполне вероятно, что вы предоставляете какие-то привилегии "сводка", сродни сводке счета или балансу.