Weave Code
Rest Upload Bundle Laravel Package
silarhi/rest-upload-bundle
A Symfony bundle for adding RESTful file-upload endpoints to your application. It streamlines receiving, storing, and managing uploaded files through a simple API, reducing boilerplate for upload workflows.
A symfony bundle to handle multiple upload ways on your REST API.
Frequently asked questions about Rest Upload Bundle
- Does silarhi/rest-upload-bundle work with Laravel?
- No. It is a Symfony bundle whose value comes from Symfony's extension model: a DependencyInjection extension compiling a Configuration tree, kernel bundle registration in config/bundles.php, and HTTP kernel event listeners. Laravel has no bundle autodiscovery, no config-tree compilation and no kernel bundle registry, so there is no ServiceProvider, publishable config or facade to lean on. Treat it as a design reference you port, not a package you install.
- How do I install and register silarhi/rest-upload-bundle?
- In a Symfony app you would run composer require silarhi/rest-upload-bundle and register the bundle in config/bundles.php, then add its settings to your config tree. Before doing that, confirm Composer resolves cleanly against your lockfile. The project shows zero stars, zero dependents and no tagged release history, so verify the version constraint you are pulling in.
- What does the REST upload endpoint actually do out of the box?
- It gives you a controller that accepts multipart uploads, validates them, persists files through a configurable storage layer with a naming strategy, and returns a JSON response containing file metadata for your frontend. The aim is to remove hand-written file-handling boilerplate. The scope is deliberately narrow: receive, validate, store, respond.
- How do I configure size limits, MIME types and allowed extensions?
- Validation is configured through the bundle's Symfony Configuration tree, so the exact keys live in its DependencyInjection configuration class rather than in the short README excerpt. Read that class before relying on defaults, and set explicit size caps and a tight MIME/extension allow-list. Never ship an upload endpoint with permissive defaults on a public API.
- Is it a drop-in for an existing Symfony application's routing and DI container?
- Yes, that is exactly the environment it was built for: Symfony-native service configuration, dependency injection, and event-dispatcher hooks into the HTTP kernel, with routing supplied by the bundle's controller. In Laravel none of that wiring exists, which is why co-installing Symfony components and bootstrapping the bundle container inside Illuminate is unsupported and brittle. That path should be rejected outright.
- Does it write files to local disk or can it use S3 and Flysystem?
- The design intent is a configurable storage layer with a naming strategy, but the assessment warns it may persist files itself using local temp files and move() rather than delegating to a Flysystem or S3 abstraction. Check the core handler classes before assuming cloud storage support. Self-persistence to local disk is a horizontal-scaling blocker for multi-node deployments.
- Which PHP and Symfony versions are supported, and is it maintained?
- That is not answerable from the available material: there is no CI badge, no tagged release history and no documented compatibility matrix, and the project has zero stars, zero dependents and a single maintainer. That profile matches a dormant personal project rather than a maintained dependency. Verify the composer.json constraints against PHP 8.x, Symfony 6 to 7, and Illuminate's transitive Symfony pins, and name an owner before adopting it.
- Is it safe to expose a public upload endpoint built on this bundle?
- Upload endpoints are among the highest-risk surfaces an API exposes: path traversal, unsafe filename handling, content-type spoofing, zip-slip and decompression bombs, memory exhaustion on large or base64 payloads, orphaned temp files, and SSRF if remote-URL ingestion exists. An unvetted, single-maintainer package has had no community security review and no CVE response surface. Do not adopt it as a runtime dependency; read the core classes first if you use it at all.
- What should Laravel developers use instead for file uploads?
- Use Laravel's native UploadedFile handling, a FormRequest with mimes, max and dimensions rules, and the Storage facade over Flysystem disks, plus queued jobs for chunk assembly. spatie/laravel-medialibrary is a reasonable choice if you need media management and conversions on top. These cover the same domain logic natively, with no fork to own and no unsupported in-process Symfony bundle.
- How much work is it to port this upload pattern to a Laravel ServiceProvider?
- The recommended path is a native reimplementation at roughly one to two engineer-days if the supported upload modes are simple: an UploadHandler interface with per-format strategies, a FormRequest for validation, Flysystem disks for storage, and queued jobs for chunk reassembly. A literal fork-and-port to a ServiceProvider plus config file and middleware costs about three to five engineer-days and leaves you with a private VCS entry and permanent fork ownership. Either way the behaviour, not the bundle, is what you are buying.
Weaver
How can I help you explore Laravel packages today?