JhaoDa

https://www.google.com/search?q=php+json+float

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

Laravel Passport это реализация OAuth, не надо понимать Passport, достаточно понять OAuth и прочитать документацию.

1. Что мы должны получить от бэкенда (LARAVEL PASSPORT) при удачной аутентификации?

Об этом сказано в спецификации OAuth и в документации Passport'а.

2. Если наш access token истек, что мы должны делать и как?

Об этом сказано в спецификации OAuth и в документации Passport'а.

3. как проверить валидность токена

Выполнив запрос с этим токеном на бэкенд либо посмотрев на срок его жизни. Об этом тоже сказано в спецификации OAuth и в документации Passport'а.

В приведённых Daria Motorina ссылках явно видно, что нынешней цветовой палитре они не соответствуют.

В документации нет какой-то особой темы, использована дефолтная палитра пакета PrismJS, который и занимается подсветкой кода.

Все пути к стилям и js скриптам пакета прописал в файле webpack.mix.js

Зря.

Правильный путь, как обычно, описан в документации.

это не нужный лишний шаг для меня если можно напрямую

Если для тебя это не нужный шаг, то не используй, в чём проблема-то?

В реальности же иногда возникает ситуация, когда создание объекта возможно как через web-интерфейс, так и, например, через консоль. Логично выделить создание объекта в некий сервис, который как раз и должен принимать DTO, ибо какой реквест в консоли?

Кроме того, применение DTO не ограничивается заменой реквестов, это способ передачи данных между слоями приложения в слоёной архитектуре, ибо зачем передавать сущности/фреймворкозависимые вещи в слой, которому о них знать не надо?

Есть — надо переопределить метод, формирующий ответ с ошибками.

В API не может быть сессий. Надо перестать изобретать велосипед и взять, например, Passport.

Если Passport использовать возможности нет, то надо перестать париться из-за запросов в базу.

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

Многабукаф и явно проступающие контуры велосипеда с квадратными колёсами видятся мне в этом вопросе.

Взять, например, Laravel и посмотреть, как это сделано там. По необходимости доработать под свои нужды. Например:

api/auth/register — регистрация
api/email/verify/{user_id}/{hash} — ссылка в письме

создаётся UnverifiedUser и сохраняется в таблицу unverified_users

Дичь №1, достаточно какого-нибудь поля email_verified = true|false.

Затем сервер возвращает ответ "202 Accepted"

Дичь №2.

Также подскажите, пожалуйста, кто должен отправлять письмо, клиент или сервер? Мне кажется, что сервер.

Это очевидно.

Т.е. для примера: есть клиент API у которого есть форма ввода логина-пароля, пользователь этого клиента вбивает свои данные, нажимает «Войти», а вот что дальше я не совсем понимаю.

Прочитать спецификацию OAuth 2.0.

Или взять готовое решение для OAuth2.0, их вагон под любой язык/фреймворк и не париться, в процессе использования изучить основы.

Конечно, если ты там не Очень_Важное_Приложение_Для_Работы_С_Конфиденциальными_Данными пишешь, тогда лучше дай себе по руками и читай спецификацию (ну или займись чем-нибудь попроще).

В документации я не нашел ничего

Правда?

Upd: в комментариях прояснилось — теоретически, надо зарегать второй mailgun-драйвер в менеджере транспортов и потом подменять инстанс SwiftMailer новым, с этим транспортом.

https://laravel.com/docs/6.x/verification