Product Decisions This Supports
- API contract design for file uploads. The core product question this package answers is: do our API consumers get to upload files as
multipart/form-data, as base64 inside a JSON body, or both? This bundle exists to make "both" cheap — it normalizes the inbound request into a standard Symfony UploadedFile so the rest of the application (validation, forms, persistence) doesn't care which transport the client used.
- Build vs. buy vs. copy. The realistic decision here is not "adopt vs. build" but "vendor/fork ~200 lines vs. write ~200 lines." Given 46 stars, zero dependents, and a last release of September 2016, the pattern is worth copying; the dependency is not worth taking on.
- Client-segment trade-offs. Base64-in-JSON is genuinely valuable when your consumers are mobile apps, SPA clients, or third-party integrators already speaking a JSON API and unwilling to switch to multipart for one endpoint. That's a product/API-ergonomics decision, and this package is a concrete prior art for how to implement it.
- Roadmap de-risking. It establishes that dual-transport upload is a solved, small-scope problem — so it should never appear on a roadmap as a multi-sprint epic. It's a supporting task inside an existing upload story.
- Scope boundary decision. This package deliberately does not do resumable/chunked uploads, storage abstraction, virus scanning, or image processing. That's a useful reminder to decompose "file uploads" into: transport normalization (this), storage (Flysystem/Vich), and post-processing (queue) — and to decide each separately.
Important scoping correction for the record: despite being surfaced in a Laravel/PHP package review, this is a Symfony bundle, not Laravel. The transport-normalization concept ports to Laravel cleanly (a middleware or form request that base64-decodes into an UploadedFile), but the code does not. If the stack is Laravel, this is reference reading only.
When to Consider This Package
Consider adopting the pattern (or forking) when:
- You're on a legacy Symfony 2.8 / 3.x application where this bundle's era-appropriate dependencies still resolve, and you need dual-transport upload support inside an existing Symfony Form workflow.
- You need the specific behavior of mapping base64 payloads onto Symfony form fields and their validation constraints with minimal glue code.
- You want a time-boxed proof of concept to show stakeholders what a JSON-native upload API feels like before committing to a custom implementation.
- You need prior art to justify (or reject) supporting base64 uploads — reading a working implementation is cheaper than debating it in the abstract.
Look elsewhere when:
- You're on Laravel, or on Symfony 5/6/7 or PHP 8+. No release in ~9 years means no maintenance, no security patches, no compatibility guarantees. Treat it as incompatible until proven otherwise.
- You need resumable or large-file uploads. Use the tus resumable upload protocol or a managed service. Chunking, retry, and integrity are the hard parts, and this bundle does not address them.
- You need production storage or processing. Pair anything you build with Flysystem + a queue-based processing pipeline; don't expect upload handling and storage to be one decision.
- Zero dependents is a red flag you can't ignore. It means almost nobody has run this in production at scale, so you are the de facto maintainer the moment you install it. For a package this small, forking with an explicit owner is strictly better than depending.
- Your API consumers are all server-side or browser-form clients. Multipart works everywhere; the base64 convenience buys you little and costs ~33% payload overhead.
How to Pitch It (Stakeholders)
For executives: There's a small, well-understood piece of plumbing that lets our API accept file uploads in more than one format — which matters for mobile and partner integrations. The open-source package that implements it is effectively abandoned (no release since 2016, no downstream users), so I do not recommend taking it as a dependency. Instead, I recommend we spend roughly one to two engineer-days implementing the same behavior in-house, scoped inside an existing upload story rather than as its own initiative. This keeps us off an unmaintained dependency, costs about the same as adopting it, and gives us a named internal owner.
For engineering: srio/rest-upload-bundle is a Symfony bundle that normalizes multipart/form-data and base64-in-JSON request bodies into UploadedFile instances so a single form/validator pipeline handles both. It's a good reference implementation of a genuinely small problem. It is not a dependency candidate: last release 2016-09, zero dependents, 46 stars, Symfony 2/3-era constraints. Recommended action: read it, then implement an equivalent request-normalization layer (Laravel middleware or Symfony request transformer) with tests. Budget the effort as a subtask, and pair the decision with separate, explicit choices on storage (Flysystem) and resumable upload (tus) so we don't accidentally imply this solves those.