docs: rewrite JsonRpcBundle docs, add SDK docs, move them under docs/api
uk/docs/api/json-rpc-bundle/functionality/notifications.md
новий файл +50
−0
Notifications
Доступно з версії 10.1.
За специфікацією JSON-RPC 2.0 запит без id — це notification: клієнт не чекає результату. Сервер не повертає на нього відповідь, а одиночна notification по HTTP отримує 204 No Content з порожнім тілом.
curl -i -X POST https://example.com/rpc \
-H 'Content-Type: application/json' -H 'Ufo-RPC-Token: <token>' \
-d '{"jsonrpc": "2.0", "method": "audit.log", "params": {"event": "login"}}'
# HTTP/1.1 204 No Content
Сигнатура методу не змінюється, його результат відкидається. Тож notifications підходять для дій «вистрілив і забув»: аудит, метрики, відправка повідомлень.
Коли виконується метод
Метод виконується на події rpc.post_response, тобто після відправлення відповіді клієнту:
- під PHP-FPM — після
fastcgi_finish_request(), клієнт не чекає; - в інших SAPI (Apache mod_php, вбудований сервер) метод теж виконується, навіть якщо клієнт уже закрив з'єднання (з 10.3), але HTTP-воркер зайнятий до завершення методу.
Виконання логується через LoggerInterface на рівні info.
Від'єднане виконання
Для рідкісних довгих notifications можна виконувати їх у від'єднаному процесі ufo:rpc:process, щоб не тримати HTTP-воркер:
ufo_json_rpc:
notification:
process: true
process_count: 2 # від'єднаних процесів одночасно (1–10); коли всі зайняті — виконується inline
Запит виконується рівно один раз: якщо від'єднаний процес не забрав його за 3 секунди, воркер виконує його сам. Те саме стосується $rpc.callback.
Кожен від'єднаний процес завантажує Symfony kernel (~200–300 мс CPU). Під навантаженням це повільніше за звичайне виконання, тож вмикайте опцію лише для рідкісних довгих методів.
Notifications у batch
У batch notification виконується згідно з режимом batch, але відповіді на неї немає. Batch лише з notifications повертає 204 без тіла.
Оновлення з 10.0
Клієнти, які надсилали запити без id і чекали на результат, мають передавати id.