Загрузка файла с побочным эффектом
Моей первой мыслью было использование GET
И это правильный ответ.Методы HTTP - это семантика, а не реализация.
HTTP не пытается требовать, чтобы результаты GET были безопасными.Для этого требуется, чтобы семантика операции была безопасной, и, следовательно, это ошибка реализации, а не интерфейса или пользователя этого интерфейса, если в результате произойдет что-либо, что приведет к потере свойства - Fielding (2002)
Генерация случайного списка значений
он просто выдает различный контент ответа каждый раз, когда клиент вызывает его, поэтому я думаю, что использование GET в порядке.
Да - опять же, если семантика безопасна , GET является хорошим выбором.
Генерация списка значенийна основе пользовательского ввода
Мне нужно отправить на сервер (относительно) длинный список элементов, которые не должны были бы соответствовать строке запроса.Вот почему я думаю, что можно использовать POST с полезной нагрузкой в теле.Но, честно говоря, это кажется странным.
Так что, если вы не беспокоитесь о длине идентификатора, GET будет обычным ответом здесь, когда весь пользовательский ввод закодирован в URI.
На данный момент у вас есть несколько вариантов.
Самый простой из них - это просто использовать POST с пользовательским вводом в теле сообщения и результирующим списком значений в ответе.,Это не должно показаться странным - POST - это метод HTTP с наименьшим семантическим ограничением.
Кроме того, вы можете переосмыслить свой протокол так, чтобы клиент создавал «ресурс запроса», используя сообщениеТело в качестве полезной нагрузки.Таким образом, POST мог бы работать здесь снова, или же вы могли бы использовать PUT (с несколько иной обработкой URI).
Третья возможность состоит в том, чтобы заглянуть в реестр Hypertext Transfer Protocol Method , чтобыПосмотрите, есть ли метод расширения с нужной вам семантикой, обращая особое внимание на то, является ли метод безопасным.ПОИСК и ОТЧЕТ могут соответствовать вашим потребностям.
Если я решу позже, я хочу записать каждый сгенерированный тест в БД, вы бы порекомендовали изменить API на POST или оставить его как есть?В случае изменения глагола HTTP клиент не заметит каких-либо функциональных изменений, но это нарушит API, поэтому с точки зрения семантики не будет ли более целесообразным использовать POST с самого начала, в конце концов?В обоих случаях смыслом будет «создать новый тест».
Нет, но все немного изменить, и все станет интересно.Интересный момент на самом деле не «запись в базу данных», а «возможность извлечь его из базы данных позже».Когда вы начинаете искать создание нового ресурса, который можно получить позже, GET перестает быть подходящим.
это нарушит API
Только потому, что выигнорируют важное ограничение REST - REST api управляется гипертекстом .В Интернете мы можем легко перейти от GET к POST, перейдя от ссылки на форму (или с формы GET к форме POST).Клиент не играет «угадать URI» или «угадать метод», потому что представление состояния включает в себя эти детали.
Но да, если вы внесете достаточно большие изменения в семантику, он не собираетсябыть обратно совместимым.Поэтому не пытайтесь делать вид, что он обратно совместим - просто создайте новый протокол, используя новые ресурсы.