Коллеги, прошу обсуждения. У меня стоит задача в получении данных через jsonRPC методом GET. Так как у jsonRPC нет обязательного транспорта, то по сути для него можно использовать любые доступные каналы, в том числе и GET. По умолчанию для совершения полного спектра действий типа CRUD и т.п. для этого юзают POST с json заголовками, и это правильно. И это все понятно как работает. У меня используется своя реализация jsonRPC и для POST меня все устраивает. Но вот возникла задача просто получать данные из вне через GET с запуском процедуры генерации PDF по некоторому UID. Т.е. юзер вводит в строку браузера или QR-коде ссылку, по которой генерируется счет/накладная или другие доки и всегда может просмотреть это дело без логина и пароля, используя токен UID. Т.е. использовать AJAX, CURL и т.п. не подходит, как того требует кошерный jsonRPC. Я перерыл кучу доков на эту тему, и по крохам собрал инфу, из которой следует что люди используют 2 базовых варианта для этих дел. Вар. 1 Код (Text): localhost/services/jsonrpc/?jsonrpc=2.0&method=Invoice&id=kDzlv3wZsgOU0A9GdGPq448tKrCQSArvt19OZ8GrSNHilsqanSIbZBdvlaDMXg6C В этом варианте для получения ответа от сервера используется запрос напрямую, без оборачивания в json. Это удобно и понятно, но не до конца как бы в духе json запроса что ли. Вар.2 Код (Text): localhost/services/jsonrpc/?request={тело json запроса по протоколу jsonRPC} Здесь мы передаем запрос в виде GET request={JSON}, где также внутри есть Код (Text): jsonrpc=2.0&method=Invoice&id=kDzlv3wZsgOU0A9GdGPq448tKrCQSArvt19OZ8GrSNHilsqanSIbZBdvlaDMXg6C но уже в json формате. Т.е. формально приходит GET с запросом request={json}, а не чистый json. Ответ при этом можно всегда получать в правильной форме. А вот с запросом как мы видим есть некоторые вопросы. Везде как мы видим есть свои компромиссы. Каких то внятных разъяснений в официальной документации по этому поводу нет вообще. Первый вариант мне напоминает REST, но тем не менее спецификация запроса в духе jsonRPC. Он удобен для отображения запроса, но в целом это не самое главное. Для второго запроса нужно формировать запрос в request={json} и сериализовать его, что является небольшим неудобством, но в целом не так страшно и жить можно. Может есть еще варианты и какой из вариантов предпочтительнее и кошернее для jsonRPC через GET? Может есть какие то наработанные практики для таких вариантов? Не хочется делать отдельный сервис для этого, так как все это можно сделать через jsonRPC, но верно ли это будет делать на jsonRPC или все же выделить этот функционал в какой то другой сервис? Не хочется плодить сервисы, но если делать красиво, то лучше тогда делать как положено, и если придется - то сделаю конечно отдельно.
Я видел первый вариант, только вы не указали параметры метода, которые остаются в JSON-формате, закодированном в URL-кодировке. Надеюсь, понятно, что не все действия можно переложить на GET. Даже с чтением чего-то быстро изменяющегося на сервере могут возникнуть проблемы, если не контролировать кеш.
Спасибо. На сколько я помню, если нет параметров то их можно не указывать. Но вообще да, параметры еще тоже добавятся если потребуется. Суть все равно примерно та же. Вариант 1 мне тоже более удобен в использовании. Остается понять на сколько это нормальная практика по сравнению со 2-м вариантом. Может быть еще люди отзовутся, было бы хорошо. Для моих задач не должно возникнуть проблем с кэшем, но вот для быстро меняющихся данных это станет задачей, которую нужно будет решать, как Вы и написали.
Длины GET-запросов имеют ограничения, во втором варианте будет некоторая замусоривающая запрос информация (JSON-обвязка). Голосую за 1-ый.
Расскажите подробнее ? Ну, по любому есть что-то в композере. В целом я бы сделал POST и слал бы туда json-body. Выигрыш в предустановленной возможности слать оче много данных и не засирать урл. Да и как-то чисто по логике, дальше упарываешься в restful api и crud получается очень даже ничего.