Самое лучшее, на мой дилетантский взгляд, это передача токена авторизации в метод. Можно, конечно, воспользоваться заголовками запроса, но json-rpc всё-таки транспортно-независимый протокол.

symbix 1 июл 2019 в 14:26

Все зависит от того, что это за токен. Если токен является неотъемлемым параметром некоего конкретного метода — тогда передавать параметром метода. А если токен на вообще доступ к данному API, тогда в заголовке самое то: в этом случае авторизация лежит вне скоупа json-rpc.

trawl 1 июл 2019 в 14:32

Авторизация и аутентификация — это скорее всего не про ограничение доступа к API. А так да, согласен

vladdnepr 1 июл 2019 в 14:46

Упс, я подумал об авторизации и аутентификации применительно к Symfony вообще, а оказалось, что имеется ввиду авторизация при запросе к API.

Самый просто способ и логичный это заголовок Authorization. В нем уже можно передавать все что нужно, будь то Basic метод, OAuth или JWT.

trawl 1 июл 2019 в 09:56

Не понял только, зачем здесь swagger, он на rpc ну вообще не ложится… Есть же SMD. sergeyfast даже как-то предлагал инструменты для визуализации

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

symbix 1 июл 2019 в 14:55

Можно класть notifications (запросы без ID), пришедшие в батчах по HTTP в очередь — вот прямо jsonrpc-запросами как есть, а фоновым процессом очередь грести и каждый ее элемент обрабатывать тем же самым JSON RPC сервером: ему ж должно быть без разницы, какой транспорт.

vladdnepr 1 июл 2019 в 14:56

Swagger здесь только как средство визуализации OpenAPI 3 JSON документации. У меня не было цели написать свою реализацию генерации JSON (на данный момент есть Swagger 2 и OpenAPI 3), поэтому воспользовался тем, что есть. Но реализовать SMD вариант документации хорошая идея, просто пока что она сейчас не в моих приоритетах.

symbix 1 июл 2019 в 14:33

Для Laravel у меня есть вот такой велосипед, может, кому пригодится.

Кстати, отвязать его от Laravel совсем несложно. Я для нового проекта активно посматриваю на SF4, скорее всего, так и сделаю. Заменить Middleware/Pipelines на PSR-15 несложно, но еще надо придумать, что делать с FormRequests (которые у меня сейчас завязаны на illuminate/validation и сделаны по аналогии с Laravel-овскими).

vladdnepr 1 июл 2019 в 15:00

Я перешел на новую работу и начал проект на Symfony 4, хотя не имел ранее опыта работы с ним, а работал с Yii2. Поначалу мозги вскипели, но теперь я не понимаю как я раньше пользовался Yii2 с его «прибитыми гвоздями» библиотеками. Так что — дерзай.

symbix 1 июл 2019 в 16:14

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

Основные претензии у меня к Eloquent, с которым следовать DDD и CQRS довольно затруднительно (да даже нормально заперсистить Aggregate Root можно только чудовищными костылями). Был странноватый, но в целом неплохой Analogue ORM, но его забросили. Доктрину, впрочем, тоже недолюбливаю за ее монстроузность: меня пугает такая масса сложного кода и архитектура с God Object-ом. Прочитал вот в дайджесте про Cycle ORM, наверное, это то, что мне надо.

Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Показать лучшие за всё время

Работа с JSON RPC в Symfony 4

Комментарии 14

Публикации

Истории