нельзя юзать, потому что не гарантируется, что запрос не реджектнется

get /api/model/7

вот это ты взял

ну не. ты не прав

а если GET /api?model=7
то ты взял или что?

ты обращаешься куда-то за чем-то.

и в чем координальная разница между тем, что ты передаешь какие-то данные в body, а не в uri, query_string?

Это ты условие наложил на данные, которые берешь из апи

ну ты уже про rest. где есть ресурсы.

конечно)

а мы про хттп. в самом http нет ресурсов

Давай на этом остановимся, это корректно звучит

и как транспорту ему пофиг, в query_string, в uri или в body ты будешь передавать

Верно

давай. потому что имхо это самое важное для новичков и не только

🤝

Get предназначен для получения данных
Вопрос почему лучше использовать get /product/id вместо get /product с телом запрос { id: 1 }

Ответов множество
1) Архитектурный, во втором примере получается, что адрес получаемой информации мы делим на 2 части, что является лапшой
2) Нам сложнее описать кеширующий\редирект сервер, потому что в первом случае мы можем отдавать кеш\редирект только по адресу, во втором нам нужно будет парсить боди. В моем примере кода для парсинга тела даже пришлось подключать бибилоитеки и увеличивать размер итогового сервера.
3) Непреемственный подход, единообразие сетевого интрерфейса, подавляющее большинство доки именно в таком стиле, где адрес получаемой инфы будет полностью находиться в URI. И это касается не только GET запросов, но и всех остальеых - адрес должен быть в параметрах, а "посылка" в боди. Написать post c боди { id: 1, newModelData: {} } ровно также плохо

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

То, что там где-то какой-то админ что-то реализовал это его частный случай и не более.
Обычно (правильно) использовать валидаторы для запросов и таких проблем быть просто не может.

А новичкам такую информацию тем более давать не стоит. Новичек может написать скопипасть из офф доки 20 строк тестового сервера и увидеть, что его обманули.
Для новичка лучше сказать, что вот есть Rest - архитектурный стиль, часто реализуется на HTTP. Вот в нем есть такие правила. Почему они такие? Для упрощения архитектуры. Это будет абсолютной правдой и не смутит человека при дайоьнейшнем изучении серверов.

Рафаил, я цитату из официальной RFC привел по http

и мы обсуждали изначально http. rest это абстракция над http. он тут вообще ни при чем

какие еще валидаторы запросов, если веб-сервер или промежуточный прокси сервер может просто забраковать гет запрос с боди? твой запрос просто не дойдет до твоей реализации. я больше об этом