Успокоительные URL с данными в строке запроса или теле запроса?
Я разработал Hexinator (Window & amp; Linux) и Synalyze It! (macOS) именно для этой цели. Эти приложения позволяют вам видеть двоичные файлы, как в других шестнадцатеричных редакторах, но дополнительно вы можете создать «грамматику» со спецификой формата двоичного файла. Грамматика содержит все строительные блоки и используется для автоматического анализа файла.
Таким образом, вы можете сохранить полученные знания в процессе анализа и применить их к нескольким файлам одновременно. Вы также можете раскрасить фрагменты файлов в разные цвета для быстрого просмотра в шестнадцатеричном редакторе. 
Результаты анализа отображаются в виде дерева, где вы также можете легко изменять файлы (применяя метод endianness и так далее).
4 ответа
Основываясь на определении PUT в HTTP, ваш первый запрос перезаписывает список игроков новым списком, который содержит только одно имя игрока. Это не добавление в список игроков.
Второй вариант для меня не имеет особого смысла. Выполнение PUT без тела на самом деле не соответствует значению PUT.
Учитывая, что одно из стандартных определений POST - это добавление к существующему ресурсу, я не уверен, почему вы этого не сделаете
POST /players
{ "name": Gretzky }
Если вы уверены, что все имена ваших игроков будут уникальными, тогда вы можете использовать PUT следующим образом:
PUT /player/Gretzky
{ "name": Gretzky }
Когда вы решаете использовать REST по HTTP, вы соглашаетесь использовать HTTP способом, определенным в RFC2616. Вот что означает ограничение единого интерфейса. И, чтобы быть педантичным, не существует такой вещи, как URL-адрес REST, и вы не можете протестировать любой вариант в браузере, потому что без javascript вы не можете выполнить PUT в браузере.
Вариант № 1 хорош, хотя, вероятно, излишний. Вариант №1 не подходит , потому что он не идемпотентен.
Вариант №2 является ПЛОХОЙ идеей. Это было бы неправильным использованием PUT. PUT следует использовать в первую очередь, когда полезная нагрузка данных запроса представляет собой непрозрачный блок данных, обычно большой или иерархический. Меньшие, неиерархические полезные данные имеют больше смысла как POST.
Также старайтесь избегать изменения состояния с помощью параметров запроса. В этом нет ничего технически опасного, если это не запрос GET, но на самом деле это не RESTful.
В этом случае вам следует сделать следующее:
POST /players HTTP/1.1
Host: www.example.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 12
name=Gretsky
Это должно вернуть ответ 201 Created . (Есть исключение: если вы не создадите ресурс сразу, и он может быть отклонен позже, вместо этого используйте 202 Accepted .)
Написание веб-службы REST, которая использует больше HTTP, чем POST и GET, должно выполняться только после того, как прочитал спецификацию HTTP ]. (Это очень полезное чтение.) Это правило будет немного более свободным, если вы используете структуру, которая принимает все решения за вас.
Насколько я понимаю, операции REST заключаются в том, что URL-адрес однозначно определяет ресурс, а тело запроса содержит представление ресурса. Учитывая это, сомнительно, действительно ли какой-либо из ваших вариантов является RESTful.
Первый будет, если предположить, что ресурс называется «Players» и GET на этом ресурсе возвращает список игроков (я не буду вдаваться в подробности вопрос о том, возвращает ли этот GET URL-адреса других ресурсов или нет ... Филдинг сказал бы, что должен, с отдельными запросами на получение данных ресурса).
Второй будет, если предположить, что тело запроса содержит информацию с ключом по имени " Грецкий ». Однако для этого вам потребуется сгенерировать ключи извне.
Используемый URL-адрес должен идентифицировать ресурс в теле, либо по компонентам пути, либо по параметрам запроса, хотя я бы предпочел компоненты пути для чего-то вроде имени или идентификатора. Тело должно быть представлением; тот, который вы ПОСТАВЛЯЕТЕ, должен быть таким же или похожим на то, что вы ПОЛУЧАЕТЕ с того же URL-адреса (или можете получить, в случае нескольких форматов)
Пример №1 неуместен, потому что вы отправляете представление для одного игрока на URL-адрес для всех игроков. В этом случае POST будет более подходящим.