Евгений Ромашкан, почитал подробнее про REST/RPC. Но в RPC же я отправляю команду на сервер в определённом формате и получаю ответ. И там есть чёткие правила, которые у меня не соблюдаются. А у себя же хочу сделать все API пo HTTP GET/POST/PUT/DELETE. Да, знаю, что REST не должен быть ограничен HTTP протоколом, но это какие-то сферические кони получаются.
Есть пример истинного Restful, чтобы посмотреть?
Александр Аксентьев, у меня последний вопрос. Зачем вообще может понадобиться иметь несколько гвардов? В документации написано, что в конфиге можно добавлять свои: например admin. Например, два session гварда с разным названием. В чем практическая польза?
Александр Аксентьев, Почитал ваш ответ и посмотрел на исходники гвардов. То есть, как я понял, алгоритм аутентификации обоих гвардов такой: сессия
1. получаем id сессии с клиента,
2. получаем id пользователя из сессии и загружаем его по этому id из базы. Если сессия умерла, то загружаем по remember_token (если есть). токен
1. просто сверяем переданный токен с полем api_token таблицы users и загружаем юзера. Не совпало? Логинься заново, получай новый, который запишется в эту таблицу.
--------------------------------------------------
То есть по факту, если хранить токен на клиенте, получаем одно и тоже поведение, просто без лишней прослойки в виде самой сессии? Разница чисто идеологическая.
Меня смутило, что по умолчанию для обычных запросов в ларе используется один способ, а для rest - второй. Ведь в паре они точно работать не будут нормально! Авторизировавшись через веб, rest запрос попросит ещё раз, но через токен. В принципе, раз у меня SPA, то я могу отказаться от web-гварда и остановиться только на токенах.
Да, но аутентификация нужна. Получается, что токен, что id сессии мы будем хранить на клиенте в куках (или в localStorage). И разница в том, что по токену не будет загружаться запись юзера из сессии, а сразу из базы. Так?
если вам нужно сделать так, что бы компоненты общались между собой, то лучше всего используйте vuex,
Я ещё только в начале документации. Не знал, что для общения компонентов между собой нужен сторонний модуль. Почему-то казалось, что взаимодействие выглядит примерно так: из Grid бы ищем компонент Settings и там вызываем его метод (который мы напишем) типа const config = root.App.Settings.getConfig() (getConfig пройдется по всем инпутам и возвратит массив значений). Ну это говнокод, наверное. Буду дальше читать.
Тимур Турсунбаев, я к тому, что вот src/index.html или картинки всегда одинаковы (то есть, не проходят никакой обработки или компиляции). При билде они должны тупо копироваться из src в dst и всё?
DevMan,
1. С чего вы взяли, что я не знаю как расшифровывается PSR? Поубавьте свой менторский тон. Он никак не добавляет убедительности в чём-то.
2. 3. Я даже слово "стандарт" нигде не упомянул... Если вы не внимально читали что вам пишут, то повторю:
PSR это лишь рекомендация. Она прижилась и используется в большинстве хорошо написанных веб-проектов (вордпресс сюда как раз не входит) и нет ни одной реальной причины городить свои велосипеды со стилями форматирования. Я пришел кому-то в команду и должен принять его велосипед? Даже PhpStorm Code Style ради такой идиотства не стану переделывать.
Пычев Анатолий, объективно у меня не получится. Ведь стили — это чистая вкусовщина. Но лично моё мнение, что буквы очень крупные, большие пробелы, большие межстрочные интервалы, курсив плохо читается.
Я использую стандартую Default тему. Она мне очень нравится.
