Weave Code
Server Laravel Package
sajya/server
Sajya Server is a Laravel package for building JSON-RPC 2.0 APIs. Define procedures, validate request parameters, apply middleware, handle batch calls and structured errors, and expose a clean RPC endpoint with minimal configuration and Laravel-native tooling.
Easy implementation of the JSON-RPC 2.0 server for the Laravel framework.
Frequently asked questions about Server
- How do I install Sajya Server in a Laravel application?
- Install it with Composer using composer require sajya/server, then publish the package configuration file. Define your procedure classes, register them in the configuration map, and expose the endpoint under a middleware group of your choice. The package has no database, queue, or infrastructure dependency, so a working pilot is typically a one-to-two-day exercise for a Laravel developer.
- How do I define and register a JSON-RPC procedure with Sajya?
- Procedures are ordinary PHP classes, which keeps them easy to test and refactor. You register each procedure in the package configuration map under the method name clients will call. Sajya resolves procedures through the Laravel service container, so you can inject dependencies into the constructor or handle method using normal Laravel dependency injection. The package then handles request dispatch, parameter binding, and the JSON-RPC response envelope.
- Does Sajya Server support batch requests and JSON-RPC notifications?
- Yes. Sajya implements JSON-RPC 2.0 over a single POST endpoint and supports batch requests, where an array of call objects is processed and returned as a batch response. Notifications, which are calls without an id, are also supported and do not produce a response entry. Named parameters are supported alongside positional parameters, so clients can send parameters as a JSON object keyed by argument name.
- How does validation work for JSON-RPC parameters in Sajya?
- Sajya integrates Laravel's validation layer, so you declare rules in your procedure and invalid input is rejected before your business logic runs. Failures are returned as structured, JSON-RPC-compliant error responses rather than generic HTTP 422 bodies, keeping the error envelope uniform for clients. This matters because JSON-RPC clients typically branch on the error object, not the HTTP status code.
- Can I apply middleware to Sajya procedures or the RPC endpoint?
- Yes. The endpoint is a normal Laravel route, so you attach route middleware groups for authentication, throttling, or logging as you would for any other route. Sajya also supports procedure-level middleware, letting you apply concerns to individual methods rather than the whole endpoint. Because dispatch runs through Laravel's normal middleware stack, existing policies and guards generally apply without modification.
- Which Laravel versions does Sajya Server support, including Laravel 13?
- Sajya 7.1.0 added Laravel 13.x compatibility through a contributed pull request from laravel-shift, the automated framework-compatibility tooling. Treat that as declared compatibility rather than verified compatibility until your own CI matrix has run the package against your Laravel version and PHP version. The presence of that automation is a positive signal that the package intends to track Laravel releases, which de-risks the medium term.
- How do I test a Sajya JSON-RPC endpoint in Laravel?
- Sajya ships Laravel-native testing helpers, and because the endpoint is a standard POST route you can also write ordinary HTTP tests that post JSON-RPC payloads and assert on the JSON structure. Test the success envelope, the error envelope, batch responses, and notification behavior separately. If you rely on custom attributes for validation or registration, add a regression test specifically for attribute resolution after upgrading to 7.1.0.
- What changed with IS_INSTANCEOF attribute retrieval in Sajya 7.1.0?
- Attribute resolution now matches using IS_INSTANCEOF instead of exact class matching, so attributes that extend the package's own attributes will also be applied to a procedure. If your procedures use custom attribute subclasses, the set of attributes applied can grow after the upgrade. Conversely, any workaround you wrote for the old exact-match behavior may now double-apply. This is the only behavioral change in the 7.1.0 release, and failures tend to surface silently as wrong validation or a procedure that appears unregistered, so write a regression test for it.
- What are the alternatives to Sajya Server for building RPC-style APIs in Laravel?
- The main alternatives are REST controllers, GraphQL via a package such as Lighthouse, or gRPC for service-to-service traffic. JSON-RPC buys you method-oriented dispatch, a uniform error envelope, and batching on a single endpoint, but it gives up HTTP semantics such as per-resource status codes, CDN caching, and standard OpenAPI tooling. Sajya is a good fit for internal service-to-service calls or partner integrations with a fixed method catalogue, and a poor fit as the primary public API for browser or mobile consumers.
- Is Sajya Server actively maintained and safe to depend on in production?
- It is a small-maintainer package with no commercial backing or vendor SLA, so overall risk is low-to-moderate and concentrated in supply chain and maintenance rather than runtime behavior. Lock-in risk is low because procedures are plain classes and the dispatch layer could be re-implemented against your own controller in days if needed. Most recent release entries are Dependabot bumps to GitHub Actions, which affect only the maintainer's CI pipeline and carry no runtime surface. Pin versions, run your own compatibility matrix, and keep a documented method catalogue with versioned method names and error codes to control contract drift.
Weaver
How can I help you explore Laravel packages today?