Weave Code
Api Bundle Laravel Package
ruwork/api-bundle
Ruwork API Bundle is a Symfony bundle for building JSON APIs in PHP. It reduces boilerplate around request handling, validation, serialization, and error responses, helping developers create consistent, maintainable backend APIs that integrate smoothly with Symfony applications.
Ruwork API Bundle is a Symfony bundle that streamlines building JSON APIs with consistent, predictable responses. It handles the repetitive plumbing of API endpoints—decoding request bodies, formatting successful responses, and converting exceptions into structured error payloads—so controllers stay focused on business logic.
- Consistent JSON response formatting for success and error cases
- Automatic exception-to-response conversion with proper HTTP status codes
- Request body decoding into typed data via Symfony Serializer
- Seamless integration with Symfony Validator for input validation
- Lightweight, configurable setup that fits existing Symfony applications
Frequently asked questions about Api Bundle
- Is ruwork/api-bundle a Laravel package?
- No. Despite often surfacing in Laravel package lists, ruwork/api-bundle is a Symfony bundle: its entry point is a Bundle subclass registered in AppKernel or bundles.php, and its behavior is delivered through kernel.event_listener and kernel.event_subscriber hooks on the HTTP kernel. It has no service provider binding, no Laravel middleware pipeline, and no event dispatcher contract Laravel can attach to. For a Laravel API, use Form Requests, API Resources, and the exception handler instead.
- What does Ruwork ApiBundle actually do?
- It is a Symfony bundle for building structured JSON APIs with less boilerplate. It offers consistent response handling, error formatting, and request/response utilities intended to keep API controllers clean, predictable, and easy to maintain. In practice that means thin plumbing around serialization, request-body conversion, and exception-to-JSON mapping.
- Is ruwork/api-bundle still maintained?
- No. The repository is archived, has zero stars and zero dependents, and the last release was 2018-08-21. There is no security patching, no issue triage, and no compatibility work for modern Symfony versions. Treat it as dead code you can read and learn from, not a dependency you can rely on.
- Which Symfony and PHP versions does ruwork/api-bundle support?
- Given the 2018 release date, it targets Symfony 3.4/4.x-era APIs such as GetResponseEvent and pre-PSR-11 container semantics. Nothing in the record proves support for Symfony 5.4, 6, or 7, or for PHP 8.1 and above. Confirm with composer require ruwork/api-bundle --dry-run inside an isolated skeleton matching your target versions before trusting the README.
- How do I install ruwork/api-bundle?
- The historical Symfony path is composer require ruwork/api-bundle followed by registering the bundle in AppKernel or bundles.php. In practice installation is not recommended, because the package is archived and unmaintained. If you need to inspect it, run a dry-run install first and use composer why and composer depends to expose its hidden sibling ruwork/* dependency graph.
- Does ruwork/api-bundle work with Symfony 6 or Symfony 7?
- Treat modern framework compatibility as unproven until verified. The bundle predates the removal of GetResponseEvent and the hardening of container semantics in Symfony 5+, so any breakage would appear at runtime rather than at install time. A dry-run install in a skeleton matching your PHP and framework versions is the only honest test.
- Does Ruwork ApiBundle leak stack traces in JSON error responses?
- That is precisely the risk at the HTTP boundary: exception-to-response mapping that serializes exception messages or traces into JSON error envelopes. Because the repository is archived, there is no maintained code path to fix a leak if one is found. Audit any fork carefully and never let the original handle production error output unchecked.
- What are the Laravel alternatives to ruwork/api-bundle?
- Laravel's native stack already covers roughly the same ground: Form Requests for validation and body parsing, API Resources for consistent response shapes, and the exception handler for JSON error formatting. On Symfony 6.3+, the maintained equivalent is #[MapRequestPayload] plus a kernel.exception listener. Either route is about a day of work, not a runtime dependency.
- Is ruwork/api-bundle safe to use in production?
- The risks concentrate in four places: abandonment means no security patches ever, the HTTP boundary is where request parsing and error mapping most often fail, framework upgrades break removed event classes at runtime, and a dormant Packagist vendor account is a small but non-zero supply-chain concern. Zero dependents also means there is no production validation signal anywhere. The reasonable conclusion is not to adopt it for a new service.
- Can I fork or vendor ruwork/api-bundle into my app?
- It is MIT licensed, so forking is legally simple. Technically it is a source-port exercise rather than an install: enumerate the listeners and subscribers, lift the semantics into first-party code with typed signatures, tests, and coverage, then keep the original out of composer.json. Also check whether its sibling ruwork/* packages are archived, since you may be forking a constellation rather than a single package.
Weaver
How can I help you explore Laravel packages today?