Какое практическое отличие для простого советского ларавельщика в обработке POST, PUT и PATCH?

Question

[Роми]

Если спуститься с небес на грешную землю, то есть ли мне какая-то практическая разница, принимаю ли я с фронта POST, PUT или PATCH, скажем, такого вида:

/api/user/1234

{"name":"Vasia","age":27}

Допустим, это таки PATCH - т.е. я делаю update данных юзера.

Но чисто практически, с точки зрения кода, будут ли какие-то отличия в зависимости от того, POST это, PUT или PATCH, кроме как в роутах?

Comments

[JhaoDa]

Слушай, уже несколько человек, пришедшие на Тостер после тебя, начали читать документацию, гуглить и думать. А ты на рекорд решил пойти?

[Роми]

JhaoDa, думаю тебе не со мной нужно общаться, а с психологом. Я решаю чисто практические вопросы связанные с программированием, а у тебя почему-то постоянно вопросы по мотивации и т.п. :)

[Максим Федоров]

Но чисто практически, с точки зрения кода, будут ли какие-то отличия в зависимости от того, POST это, PUT или PATCH, кроме как в роутах?

Практически — это соблюдение протокола и множества рпограмм, верных ожиданий др программистов и поддержки кода, понимание семантики проекта с тчоки зрения http-приложения

если вы один и плевать, что будет после вас – вы можете все и по ftp протоколу сделать или через get, кто ж запретит

по протоколу: обновление через PATCH, добавление через POST, удаление через DELETE, поулчение через GET
почему? потому что в семантике слов указано то, что они делают (GET – получить, DELETE — удалить)

[Роми]

Лентюй, хотите открыть на чужом сайте бюро платных консультаций? Откройте на своем. А здесь сервис БЕСПЛАТНЫХ вопросов и ответов. Разве нет?

[Роми]

Максим Федоров, это как бы всё понятно. Вопрос был о том, есть ли практические отличия с точки зрения написания кода для обработки таких запросов, кроме как в роутах.

[Максим Федоров]

Роми,
HTTP — это протокол (считай свод правил, спецификация, а не реализация)
Потому нет практической разницы

https://ru.wikipedia.org/wiki/%D0%9F%D1%80%D0%BE%D...

[Роми]

Лентюй, ты реально думаешь что мне интересны эти твои мысли? Да они мне ...й не нужны :D От чистого сердца говорю.

Answer 1

[jazzus]

Разница в том, что это разные маршруты. не нужно создавать users/123/update и users/133/delete. 1 урл users/123 с 3мя методами = 3 урла и все понятно, что каждый делает. Для Ларавельщика особенно критично ибо он юзает ресурсные маршруты для которых все эти методы и придуманы. а если ларавел в ларавел не использовать, то да - удаление гет запросом или другие похожие говноварианты прокатят без каких-то тех ограничений, исключений итд.

Comments

[Роми]

т.е. таки отличий кроме как в роутах не будет?

ок, спасибо!

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

[jazzus]

Роми, вообще никаких. Можно хоть все приложение в гет маршрутах оформить. Многие ларавельщики, особо ратующие за доку сами юзают максимум гет/пост. Какие там ресурсные маршруты, че за patch тем более put никто особо не парится.

[Роми]

jazzus, ну, это да, такое - тут нужна мотивация, чтобы проникнуться этой философией :) Да и вообще, в ларавель есть великолепный метод: ANY )))))))))))

[jazzus]

Роми, да, я тоже раньше думал, что это все снобизм. Пока не попробовал связку ресурсные маршруты одной строчкой кода, генерация ресурсного контроллера 1й командой и политик к нему вызываемом в конструкторе одной строчкой кода сразу для всех методов. Ты сделал КЛАССНУЮ безопасную архитектуру за 5 минут. Гораздо быстрее чем писать обслуживание для any или свои дырявые маршруты для ресурсов. Не нужно уже ничего дебажить - все четко работает сразу. В Ларавел юзать его функционал - это экономить время и писать железный код, а не следование какой-то там философии. Мне на философии положить.

[Роми]

jazzus, да я ж не спорю )) я сам к этому тоже пришел )) обеими руками за автоматизацию!))

И да:

...и политик к нему вызываемом в конструкторе одной строчкой кода сразу для всех методов.

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

спасибо.

[jazzus]

Роми, прописываешь в конструкторе ресурсного контроллера
$this->authorizeResource(Project::class, 'project');
и у тебя автоматом связываются методы ProjectPolicy с методами контроллера

[Роми]

jazzus, спасибо большое!

Answer 2

[Роми]

Трансформирую, пожалуй, ответ от jazzus :)

- НЕТ, никаких практических отличий в коде, кроме как в роутах - нет.

Answer 3

[Сергей Горностаев]

POST - создать сущность
PUT - обновить сущность целиком
PATCH - обновить часть сущности

Comments

[Роми]

Спасибо кэп! :)

Но чисто практически, с точки зрения кода, будут ли какие-то отличия в зависимости от того, POST это, PUT или PATCH, кроме как в роутах?

?

[Василий Банников]

Роми, пост будет создавать объект, put будет всё перезаписывать, а PATCH Будет разбирать jsonpatch запрос :) ваш кэп

Answer 4

[NubasLol]

Это все было придумано много лет назад, когда сайты состояли из статических файлов, и все эти методы были применимы к ним.

HTTP был придуман намного раньше чем появился rest. В рест у нас нет метода put, path. В рест не метода head.

Методы http не тоже самое что метожы crud.

По этому как реализовать свой rest сугубо твой выбор.

Существенная разница есть между get и post.

Ну я ещё использую delete. Put и path никогда не использую.

Все решаеься документаций. Rest не жёсткий стандарт, а набор практик, по организацию api

Вот был когда то в почете wsdl там все было жёстко и поп протоколу.

Comments

[Роми]

HTTP был придуман намного раньше чем появился rest

Ну, кстати, PUT, PATCH и пр тоже в HTTP не сразу появились :) В первых версиях этого не было ))

Это коль уж речь о ретроспективе зашла))

[NubasLol]

Роми, ну да, действительно.

В любом случае, толку от него никакой нет.

Даже html 5 форма только get или post бывает

[Роми]

NubasLol,

Даже html 5 форма только get или post бывает

кстати, очень резонное замечание. респект.

[Роми]

NubasLol, другое дело, что REST API ориентирован на ЛЮБЫЕ интерфейсы, не только html формы, но и мобильные, и даже десктопные приложения.

[NubasLol]

Роми, опять же, это все решается документаций) я лично не вижу никакого смысла в put и patch. И не использую.

А мои фронты используют те методы, которые я для них сделал и описал. Вот и все.

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

[Роми]

NubasLol, )))))))))

Ну, тут, да, всякое бывает)))

[jazzus]

NubasLol, ресурсные маршруты-контроллеры-политики тоже не используешь?

[NubasLol]

jazzus, да, не использую

Бесполезные вещи как по мне. В реальном приложении очень редко нужен обычный crud.

А политики впринципе неудобная вещь, и мало полезная.

Есть другие инструменты

[jazzus]

NubasLol, так мало crud, что Ларавел решил его автоматизировать. Тостер реальное приложение? Здесь дофига круд. Вот сейчас я коммент сохраняю - это create/store. А когда ты прочитаешь это index)) И чтобы ты его не изменил правило прописано в политике user->id === $comment->user_id. Это неудобно? У меня в приложении дофига crud и у тебя думаю немало. Попробуй использовать фреймворк вместо инструментов, там одни бонусы.

[NubasLol]

jazzus, применение промокода, это create, store или index?

[jazzus]

NubasLol, я где-то писал, что все маршруты должны быть ресурсными? Маршруты разные и все от приложения зависит. Но в большей части известных приложения в тч на Тостере дофигища crud и с Ларавел их оформить гораздо проще и быстрее, чем вручную.

[NubasLol]

jazzus, у меня нет проблем с тем, что бы скопировать, и вставить))

А чистых круд роутов со всеми методами практически не бывает в моей практике

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

На то и фреймворк, что бы предоставить множество инструментов, а мы программисты уже решаем как и где их использовать)

[jazzus]

NubasLol,

у меня нет проблем с тем, что бы скопировать, и вставить))

Так и я о том. С ресурсами один раз копировать и вставить (если ide барахлит). А свои маршруты - 6 раз)

А чистых круд роутов со всеми методами практически не бывает в моей практике

Комменты не делал? Посты тоже? Добавление товаров? В любом случае есть метод only или except

На то и фреймворк, что бы предоставить множество инструментов, а мы программисты уже решаем как и где их использовать)

Ну хз. Я логики в неиспользовании фреймворка не вижу. Если нужны ресурсные маршруты нет смысла их не использовать. Если политики нет смысла тянуть какие-то инструменты.

[NubasLol]

jazzus,

Так и я о том. С ресурсами один раз копировать и вставить (если ide барахлит). А свои маршруты - 6 раз)

После гошки это вообще норма, копировать и вставлять))))

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

Route::group(['prefix' => 'fcm-tokens', 'middleware' => 'pre.auth:api'], function () {
    Route::post('/store', 'FcmTokenController@store');
    Route::post('/delete', 'FcmTokenController@delete');
});

Route::group(['prefix' => 'ratings'], function () {
    Route::get('/', 'RatingController@index');
});

Route::group(['prefix' => 'articles'], function () {
    Route::get('/index', 'ArticleController@index');
    Route::get('/latest', 'ArticleController@latest');
    Route::get('/search', 'ArticleController@search');
});

Route::group(['prefix' => 'youtube-videos'], function () {
    Route::get('/index', 'YoutubeVideoController@index');
    Route::get('/latest', 'YoutubeVideoController@latest');
});

Ну политики да, стоило бы использовать наверное. Ну я я обычно обхожусь так user->relations()->where('...)->firstOrFail()

[jazzus]

NubasLol, model binding тоже не используешь?)) с ним политики проявляются во всей красе. latest - это сортировка? Зачем тебе ее в отдельный маршрут, а не параметром в реквест и в метод index? Первый блок можно в ресурсный маршрут убрать с only store/delete. Автоматом контроллер и прикрутить права. Политики, конечно лучше использовать вместо фейлов, как минимум, чтобы получить правильные 403, а 404 уже model binding с его фейлами (чтобы запросы не дублировать)

[jazzus]

NubasLol, я так делаю

Route::namespace('Project')->middleware('author')->group(function () {

    // здесь еще роуты

    Route::apiResource('projects', 'ProjectController');

    Route::namespace ('Comment')->group(function () {

        Route::prefix('parents.')->name('parents.')->group(function () {

            // здесь еще роуты

            Route::apiResource('projects.comments', 'ParentProjectCommentController');
        });

        Route::prefix('replies')->name('replies.')->group(function () {

            // здесь еще роуты

            Route::apiResource('projects.comments', 'ReplyProjectCommentController')
                ->only('store', 'update', 'destroy');
        });
    });

});

[jazzus]

Route::resource('adverts', 'Advert\AdvertController')->except('update');

Route::namespace ('Advert')->prefix('adverts')->name('adverts.')->middleware('auth')->group(function () {

    Route::post('{advert}/update', 'AdvertController@update')->name('update');
    Route::patch('{advert}/activate', 'AdvertController@activate')->name('activate');
    Route::patch('{advert}/deactivate', 'AdvertController@deactivate')->name('deactivate');

});

[NubasLol]

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

Зачем тебе ее в отдельный маршрут, а не параметром в реквест и в метод index

В индекс есть пагинация, в latest ее нет, и там только 3 модели отдается. По этому разделил на разные роуты. Так удобнее

[jazzus]

NubasLol, лучше юзать ресурсы, это ведь сокращение кода и времени разработки в разы

[Роми]

NubasLol, это PATCH к основной сущности, где промокод - свойство :) Ну, это если по REST делать ))

[Роми]

jazzus, а у тебя есть в паблике где-то код с твоими крудами на ларавеле? Я бы, с удовольствием ознакомился, чисто в познавательно-учебных целях )) Ибо дока в ларе слишком уж мало экзамплов содержит - приходится каждый раз мозг напрягать, когда надо реализовать ту или иную фичу, а они ведь почти все по идее - типовые, и опытный разработчик их по 10 за день делает...

[NubasLol]

Роми, промкод не свойство, он дает какой-то бонус

[jazzus]

Роми, у меня в пабликах проектов нет, я только для работающих делал, а их код особо показывать нельзя. Только какими-то такими кусками. Но здесь от меня 0, я из доки все беру. Мне ее зауши. А когда еще blade компоненты там появились с классами, так еще 50% своего проектирования выпилилось. Ибо они как репозитории хорошо работают и переиспользуются в легкую. Из дополнительного только трейты (для общего кода объектов с $this) и сервис классы (для процессов). Если Ларавел вообще не знаешь, то лучше видеоуроки, а потом юзать только документацию т.к. в статьях и видео очень часто пилят велосипеды от которых потом сложно переучиваться.

[jazzus]

Роми,

Ибо дока в ларе слишком уж мало экзамплов содержит - приходится каждый раз мозг напрягать, когда надо реализовать ту или иную фичу

Не согласен. В доке много примеров где и когда. Их примеры можно брать как за бест практику проектирования. Вот ты спрашивал про валидацию. В доке прямой пример где когда и как https://laravel.com/docs/8.x/validation#creating-f.... Там видно, что не в мидлварях и не в своих классах. Все по такой же схеме

[Роми]

jazzus,

В доке много примеров где и когда. Их примеры можно брать как за бест практику проектирования.

При условии, что ты знаешь, что в роуты бизнес-логику писать нельзя, как это происходит всю дорогу в доке к Ларке ))) Но это только очевидный пример я привел - а сколько там еще НЕочевидных?

[Роми]

jazzus,

model binding тоже не используешь?))

имеет смысл?

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

но я на этом мнении не настаиваю, впрочем )

я интересуюсь твоим, вижу что ты нативный функционал Лары используешь давно и плотно))) твое мнение ценно здесь)

[jazzus]

Роми, return 'Hello World'; это не бизнес логика, а проверка связи))

Но это только очевидный пример я привел - а сколько там еще НЕочевидных?

Поэтому к доке нужно приходить подготовленным. Я и написал - видеоуроки, ларакаст и тд. Можно и статьи читать и на Тостере спрашивать. Собрать базу, потом все забыть и в документацию за бест практиками)

[jazzus]

Роми,

слишком дофига зависимостей получается по ходу выполнения реквеста

насчет зависимостей не понял. наркотические чтоли? Указываешь {project} в роуте Project $project в аргументах контроллера и он тебе автоматом применяет findOrFail. А в ресурсах там вообще все генерится автоматом и в роутах и в контроллерах и в политиках. Потом с этим $project везде работаешь и все.

[NubasLol]

jazzus, у вас и фронт на blade?

[Роми]

jazzus, скажи, а ты когда-нибудь с таким сталкивался:

https://qna.habr.com/q/1064018

??

[jazzus]

NubasLol, blade + vue в виде множества компонентов, там где нужна реактивность. а что не так с blade?

[NubasLol]

jazzus, просто интересно было)

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

По этому до сих пор Блэйд звучит для меня как что-то ужасное.

[jazzus]

NubasLol, у меня фронтов нет, я сам фронт и бэк) на самом деле удобный, надо распробовать. И связка с Ларавел - директивы с политиками, хелперы итд Компоненты, которые с 7-й версии появились вообще кайф т.к. у каждого есть свой класс. Сильно зачистил код.

[NubasLol]

jazzus, ого, и верстаешь сам?

У меня вот какое-то отвращение ко всему фронтовому, хотя понимаю что хорошо бы знать js как минимум, и уметь в вёрстке хоть немного поправить. Но пока я не переборол себя.

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

[jazzus]

NubasLol, не я прямо верстать с нуля тоже не возьмусь. Как-то пробовал и понял, что не мое. Как и дизайн. Юзаю готовую Bootstrap верстку) ПОделить на шаблоны в блейд проблемы нет, а там какие-то небольшие вещи формы, карты итд не сложно. css тоже подправлю. А vue очень легкий фреймворк. Его за день можно выучить для типовых задач.

[Роми]

jazzus,

А vue очень легкий фреймворк. Его за день можно выучить для типовых задач.

Угу, это когда уже освоил - то всегда кажется просто)) а поначалу просто скрючивает мозги от принципиально новых концепций и конструкций)) все эти пропсы, шмопсы, туда-сюда)) К тому ж все экзамплы в доке написаны для ситуации, когда ты юзаешь Vue через CDN, а в основном-то работают с vue-cli - и постоянная трансляция кода в голове из одной системы координат в другую - тоже дополнительная боль.

Ах да, JS для начала тоже неплохо бы знать на хорошем уровне ))

Так что оценка "Его за день можно выучить для типовых задач" - мягко-говоря, не совсем адекватна реальности ))))))))))))

[NubasLol]

Роми, ну вью сильно проще реакта, я еще джуном делал с ним правки и какие-то доработки в crm. Он в целом понятно читается.

Вот реакт да, там без подготовки ничего не поймешь

[jazzus]

Роми, я как первое видео по vue посмотрел везде этот шаблон юзаю. Потом усложнилось немного с компонентами, эмитами итд, но в целом все к этому темплейту сводится.

<template>
  <span>
  </span>
</template>

<script>

  export default {

    components: {
    },

    data() {
      return {
    
      }
    },

    props: {
      data: Object,
    },

    methods: {

    },

    mounted() {

    },

    computed: {
        
    }

}

</script>

<style>
</style>

[jazzus]

Но мне проще т.к. делаю с blade. Если весь фронт на вью то конечно в разы сложнее.

[Роми]

NubasLol, ну, React - потому что JSX, и потому что дока менее внятная, чем у Vue. У Vue дока годная, на уровне Laravel.

[Роми]

jazzus, ну, в чем-то сложнее, а чем-то и проще, потому что можно использовать Vue-фреймворки типа Nuxt, а в нем изначально уже структура настроена, роуты-шмоуты ))) и т.п. С другой стороны, в проде поднимать проект на vue-cli - такое себе )) ну, по крайней мере, если не занимаешься этим постоянно.

Так что соглашусь с тобой в этом :)

[Роми]

jazzus, вот, сразу видно человека с методичным подходом! Уважаю. А я, блин, каждый раз, когда дело доходит до Vue - начинаю судорожно рыться - искать свои старые проекты, чтобы оттуда копипастить типовые решения))))))))))

[Роми]

jazzus, я кстати computed практически не использовал никогда, хз почему, мб потому что так и не понял толком о чем оно ))) Да и вообще, для меня Vue - это просто как основа для Element UI )) Ну, т.е. тоже просто как средство быстро слепить морду для админки ))

[Роми]

...я вообще в full-stack уже не верю)) банально не влезает в голову столько всего разного)))

[jazzus]

Роми, фулстэки разные бывают. если весь фронт на вью какое-нибудь реактивное спа то да. А если компоненты+blade вполне. blade это не совсем фронт. Он сильно с Ларавел и бэком связан. Фронты без знаний ларавел на нем ничего не сделают.

[NubasLol]

Роми, бывают фуллстэки, но тут нужен талант+куча времени.

Если работать как обычно, и дома что-то почитывать, конечно ничего не выйдет.

У меня был знакомый фуллстэк, который от того, что сам делал мобильные приложения, до того что настраивал ci cd на gitlab+кубер.

Answer 5

[Вячеслав Плиско]

С практической точки зрения важное отличие - GET, POST нативно поддерживаются http клиентами и браузерами. А PUT, DELETE, PATCH и т.д. - не везде и приходится эмулировать через скрытое поле в случае Laravel.