Всем привет! Часто пишу апи и думаю, как правильно мапить

REST методы на CRUD операции.
На данный момент пришел вот к такому:
GET - READ
POST - CREATE
PUT - UPDATE
DELETE - DELETE
Но есть несколько вопросов:
1. Встретил (в вики), что ПОСТ сюда не подходит (аргументацию не особо понял) и вместо него надо использовать PUT т.к. PUT - это CREATE/UPDATE. Что думаете про это? Как вы делаете?
2. Мне часто надо сделать такой метод апишки, который, например, принимает массив id и возвращает инфу по каждому id. С одной стороны это явный GET. Но иногда id бывает много и они не помещаются в url (да и в принципе мне как-то не нравится в урл их пихать) - тогда решение слать JSON в теле запроса. Но тело в GET запросе - против рекомендаций протокола.
Или, например, не массив id, а просто набор филтров, по которому сервис должен отдать все удовлетворяющие записи. Выходит 2 возможных способа
а) Метод Get, но с телом запроса
б) Метод POST, но в этом случае меняется логика, т.к. POST - это больше создать
Не могу найти удовлетворяющее решение. Как вы делаете?

Put для создания только если известен id, а если нет - post. Для чтения с телом запроса тоже put сгодится, ибо идемпотентен.

Но put же по смыслу "создать\обновить", а мы его используем для "получить"

По какому такому смыслу?

возьмите какую-то спецификацию и делайте по ней

у rest вроде это описано чётко. Если повторный запрос по тому же пути вызовет новые изменения (создастся ещё одна запись, увеличится счётчик и т.п.) - это post, иначе - put.

Ну это требование идет из: пут - идемпотентен пост - нет Но что делать, когда я получаю информацию, а тело засунуть в ГЕТ запрос не могу хз. Выходит надо использовать ПУТ, но ПУТ - это, как минимум, переводится положить. Я не утверждаю, что перевод это главный аргумент, но как бы не просто так там такое слово..

А что ты там такое получаешь, что тебе query параметров не хватает для передачи данных?

Такое слово было придумано за долго до современного веба.

как минимум квери данные не безопасно передавать если там сенсивити данные (логины, пароли и тд)

Например, id - это строка из 10 символов. И надо получить по 1000 таких айди данные.

То есть постом безопасно, да?

более безопасно, да

чем?

пост в логах не осядет

если у Вас есть логи и они утекут, будет беда

Это уже от логов зависит, но в целом есть смысл, согласен.

ну тогда не парься и делай пост. я обычно такого правила придерживаюсь - не понятно какой метод использовать - значит будет post.

Вот и мне кажется, что это не особо подходит для таких задач.

Это это что? Спецификация протокола http?

ну или например делать GET /url/to/delete?by_id=id тоже плохая идея, тут тоже безопаснее пост использовать

Да. Ну и в принципе сама необходимость маппить набор этих слов на действия, которые ты совершаешь. Не всегда это удается легко.

вообще тут DELETE прям и просится. но да, любые запросы-действия через гет низя никогда

https://www.youtube.com/watch?v=Txi95RQPRP0

Для этого delete придуман, но при чем тут безопасность?...

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

У этих слов есть достаточно однозначная спецификация (в отличии от статус кодов), не думайте о словах, а думайте о двух неразрешимых проблемах в it: инвалидация кеша и наименование переменных.

вот тут это обсуждается как плохая идея

а это не плохая идея, за такое надо ломать пальцы

то есть тут Вы видите что я предложил так делать?

прежде чем ломать пальцы, надо объяснить почему это "плохо", для начала. А то как будто Вы сели за компьютер и сразу знали что так делать нельзя и за это ломать надо пальцы

Зачем мне эта ссылка?

дольше объяснять чем ломать

там есть про REST

Там есть 1 видео, где набор технологий перечисляется. Выглядит, как реклама.

ну тогда автор миллиардер )))

лучше Вам никогда не метить в "тим-лида"

я таких не нанимаю

да, я таких как Вы тоже )

и это правильно

я кстати преподователем работаю, записывайтесь ко мне на курс

нет, спасибо, боюсь Вы не сможете меня ничему научить своими методами "ломать пальцы" )

у страха глаза велики

таких как Вы очень много людей, кто не ломает пальцы ) конкуренция у Вас высокая

я думаю вы хотели сказать наоборот

честно сказать, за долгую практику видел именно GET - READ, POST - CREATE (ACTION), PUT - UPDATE (OR UPGRADE), DELETE - DELETE - это как бы ок подход, он привычный многим, лучше делать так чем как то иначе а потом другие люди которые будут работать над тем же кодом будут путаться

С созданием вопрос есть - если id задано сверху, то нужно подумать что лучше post или put. Какое поведение должно быть при повторном запросе? Если 200, то я бы пут брал, если 400 - пост.

а зачем id задавать сверху ?

Бывает. И не так редко как хотелось бы.

проще валидировать когда сверху нету не каких ид, а все в теле

Сверху в смысле свыше, в смысле из внешнего сервиса приходит.

Затем, чтобы был просмотр) Вам ее прислал автор видео

шарит

пфф, зависит от того, что в логи писать

Любой лог являет собой ценность для BB тестирования

я же сказал, в гет нельзя передавать сенсив дату, есть множество секьюрных моментов на этот счет. А в целом можно создавать или редактировать или удалять все через гет, но так делать нельзя

утекшие логи — отвратительный аргумент, абсолютно это безопасность уже внутри бекенда, при желании можно и хедеры вытащить, и тело

логировать аксес логи это нормально, по закону GDPR Вы не имеет права хранить определенную информацию на своем сервере о пользователях и если будете ее передавать через ГЕТ, Вы будете нарушать этот закон если включен аксес лог, как Вам такой аргумент?

это здесь при чем?

все, не хочу объяснять дальше, проехали.

@Rostislaved