PO
если у тебя авторизация или передача чувствительных для пользователя данных – только post
Size: a a a
2020 July 04
PO
если форм фильтрации данных или поиска то лучше get
b
понял ))
b
спасибо ) пойду закреплять
PO
то есть логин/пароль/паспортные данные - post
PO
цвет кроксов - гет потому что ты просишь выдать список тапок ограниченный по цвету
PO
но тебя никто не ограничивает послать фильтр и постом
PO
просто работать с такмим запросами будет сложней
PO
потому что get сохоаняет состояние в url а пост нет, тебе надо будет каждый раз обновлять поля, или как-то еще выкручиваться. Если надо будет дополнить запрос
PO
при этом обрати внимание, что есть еще и такие методы
PO
с которыми php работать не умеет, напрямую
PO
в том же ларавель тебе надо будет через post дополнительным полем передавать название метода которым бы ты хотел отработать )
PO
если рассматривать REST то:
– GET - запрос данных с сервера, возможно с указанием параметров для выборки (пагинация, фильтры и тп)
– POST - создание новых объектов
– PATCH - обновление существующих записей
– DELETE - очевидно
– GET - запрос данных с сервера, возможно с указанием параметров для выборки (пагинация, фильтры и тп)
– POST - создание новых объектов
– PATCH - обновление существующих записей
– DELETE - очевидно
PO
при этом post/patch/delete/put могут передавать как массивом, так и в теле. Например отправка данных в виде json
PO
get тооооооже может ) но нормальные сервера такое поведение фильтруют
b
get тооооооже может ) но нормальные сервера такое поведение фильтруют
по той же причине, что небезопасно 🤔
PO
Нет :)
b
а эт точно все пригодится фронту? )
PO
Такая спецификация протокола
b
Такая спецификация протокола
понял принял