Per спецификация полезная нагрузка запроса GET не определена.Поэтому вы должны воздерживаться от отправки тела с запросом GET.Как уже указывал Давиде, вам следует вместо этого переключиться на POST, поскольку здесь семантика полученной полезной нагрузки определяется вами, сопровождающим сервера / API.
Однако, поскольку вы пометили свой пост rest вам, вероятно, следует подумать о копировании концепций, используемых в Интернете уже более 2 десятилетий, и преобразовании их в свой дизайн API.Во-первых, архитектура REST не заботится о структуре вашего URI.Сам URI является просто указателем на ресурс, и клиентам не нужно ни интерпретировать его, ни взламывать его.Вся информация, необходимая клиенту для выбора, должна быть предоставлена сервером для начала.Поскольку клиенты не должны анализировать и интерпретировать URI, как они определяют, полезен ли URI для клиента или нет?
Ну, как мы, люди, взаимодействуем с URI на веб-страницах?Обычно они снабжены удобочитаемым текстом, который суммирует содержание этой ссылки (как в спецификации, т.е. выше).Такие короткие, но значимые имена обычно называют именами связей и должны быть «прикреплены» к каждому URI.Клиент, считывающий такие имена отношений ссылок и просто вызывающий соответствующий URI, сможет продолжить свою задачу, если серверу когда-либо понадобится изменить свою структуру URI.Это один из важных шагов на пути отделения клиентов от серверов.Такие имена отношений ссылок должны быть стандартизированными , но могут также указываться в общеизвестных или указываться в самих медиа-типах.
Распространенная ошибка многих так называемых "API REST""do поддерживает только application/xml и / или application/json.Это очень плохие типы носителей в архитектуре REST, поскольку они определяют только используемый синтаксис, но не семантику соответствующих элементов.Таким образом, клиенту трудно определить цель такого документа и легко попасть в ловушку typed ресурса и предположить, что определенный ресурс имеет определенный тип.Если такое (нестандартизированное) представление изменяется, велика вероятность того, что клиент прервет дальнейшее взаимодействие с этим сервисом / API.
Типы носителей - это более или менее стандартизированные правила обработки для определенной полученной полезной нагрузки, которыедолжен помочь дать получателю какое-то значение контента и того, что он может с ним делать.Один, вероятно, хорошо известный тип мультимедиа - это HTML, который определяет, когда определенные элементы осуществимы и какое ограничение имеет каждый элемент.Он также определяет способ визуализации определенных элементов и обратную совместимость с предыдущими версиями.Это стандарт де-факто, когда речь заходит о поддержке ссылок и ссылочных отношений.Хотя HAL , Collection + JSON , ... являются шагами в правильном направлении с точки зрения поддержки ссылок и имен отношений, они далеки от предоставления той же семантики, что и HTML,хотя они должны быть предпочтительнее простого JSON, поскольку они не только определяют синтаксис, но и семантику определенных элементов, таких как _links, то есть которые помогают клиенту отличать ссылки от контента.
Типы медиа особенно важны с точки зрениясогласования типа контента, когда клиент запрашивает у сервера вернуть формат представления, который понимает клиент.Если сервер не может создать такое представление, он сообщит клиенту с достаточно выразительным кодом ошибки (406).Если сервер не может обработать тип мультимедиа, предоставленный клиентом (в операциях POST, PUT, PATCH, ...), он также сообщит клиенту, что он не понимает такой формат (415).
Общий совет по разработке REST API заключается в том, чтобы думать об API с точки зрения веб-сервера, а также описывать весь процесс взаимодействия с ним.Т.е. если клиент должен выполнить определенный ввод, ему не следует отправлять на сервер только файл JSON воспроизведения с некоторыми случайными полями (указанными в некоторой внешней документации), но сервер должен научить клиента отправлять такой запрос для начала.,Подобно веб-формам, где люди должны вводить текст и прочее, API-интерфейсы REST должны возвращать медиа-тип, представляющий формуляр, который сообщает клиенту, какие поля ожидает сервер, какую операцию использовать и цель для отправки полезной нагрузки.
Что касается самого вопроса, я не уверен, почему ваш сотрудник так заинтересован в удалении параметров из URI.Как упомянуто в моем первом параграфе об отправке полезной нагрузки, вам нужно переключиться на POST и, следовательно, автоматически потерять гарантированные safe и idempotent функции операции GET, кроме того, что они не будут кэшироваться по умолчанию.
То, что вы можете сделать, т.е. позволить пользователям или вашим коллегам предварительно сконфигурировать определенные запросы и создать короткие / крошечные URL-адреса для этих предварительно сконфигурированных URI.Здесь вы должны предоставить клиенту тип мультимедиа, похожий на форму, где он может выбрать опции для выбора и ввести дополнительные необходимые данные.Получив такой запрос, вы сохраняете такую предварительную конфигурацию и возвращаете короткий / миниатюрный URL-адрес для этой предварительной конфигурации в заголовке Location ответа.Вам также следует добавить предварительно настроенные ссылки в обычный ответ, чтобы клиент мог вызвать его, если он не сохранил его сразу после сохранения.Благодаря этому вы по-прежнему получаете преимущества операции GET, при этом вы можете гибко добавлять новые или настраивать существующие запросы на лету.Как упоминалось ранее, клиент не сможет много использовать такие ссылки в простом application/json представлении.Если клиент поддерживает application/hal+json, он может, по крайней мере, знать, что такое link-отношение и ссылки, и, следовательно, иметь возможность искать и вызывать URI через сопровождающее имя отношения link.По сути, это дает вам свободу в дальнейшем изменять структуру URI, если это необходимо, не затрагивая клиента.