- Is gointegro/hateoas-bundle a Laravel package?
- No. Despite being catalogued under Laravel/PHP searches, gointegro/hateoas-bundle is a Symfony bundle that assumes a Symfony kernel, HTTP kernel event listeners, compiler passes, Doctrine annotations for resource metadata, and Doctrine ORM entities. Laravel does not provide those integration surfaces. Only the underlying gointegro/hateoas core and the serialization and metadata concepts are realistically reusable.
- Can I use gointegro/hateoas-bundle with Laravel and Eloquent?
- Not directly. The bundle's integration points assume Doctrine ORM entities and Symfony's container and event system, while Laravel uses Eloquent and a different routing and serialization layer. A Laravel port would mean re-implementing the metadata-driven serializer, association traversal, and pagination adapter against Eloquent, which is a multi-week spike rather than an afternoon composer require. Most teams are better off mining the bundle for design ideas and building against Laravel primitives.
- What Laravel versions does this package support?
- None. There is no Laravel service provider, facade, or Eloquent driver in gointegro/hateoas-bundle, so Laravel version compatibility is not applicable. Its Composer constraints target Symfony, Doctrine, and PSR components instead. Check composer.json rather than the README for the real version ceilings.
- How do I install and configure gointegro/hateoas-bundle?
- In a Symfony application you install it with Composer, register the bundle in the kernel, and configure resource metadata for your Doctrine entities. Setup also involves wiring serialization, pagination, and any metadata caching into the Symfony service container. In Laravel there is nothing to register because the bundle has no Laravel integration; you would be porting glue code, not configuring a package.
- What features does GoIntegro Hateoas Bundle provide?
- It brings a JSON:API-style HATEOAS response format to Symfony REST APIs, including pagination, sorting, filtering, sparse fieldsets, and embedded related resources. Annotations and helpers let you expose resources and links with minimal configuration instead of hand-writing serializers per endpoint. In a Symfony and Doctrine codebase that is a genuine productivity win; in Laravel you would need to rebuild those features on API Resources and whenLoaded.
- Does gointegro/hateoas-bundle support Doctrine attributes or only annotations?
- The design is annotation-era: resource metadata is driven by Doctrine annotations, which are on a deprecation path across the PHP ecosystem as projects migrate to attributes. That is a known future break rather than a hypothetical one. Verify the latest tag against composer.json and expect to migrate metadata to attributes or maintain a fork.
- How do I implement HATEOAS or JSON:API in Laravel without this bundle?
- Build a thin HAL layer instead of porting Doctrine metadata. That typically means a serializer such as nocarrier/hal or a small custom transformer, Laravel API Resources with whenLoaded for relation embedding, and middleware that parses allow-listed sparse fieldsets and include parameters. This approach is usually smaller, safer, and easier to own than adapting a Symfony bundle to Eloquent.
- Is gointegro/hateoas-bundle actively maintained and production ready?
- The maintenance signal is weak: roughly 68 stars and zero dependents means little production validation and no downstream pressure to keep it current with Symfony, Doctrine, or PHP releases. Treat unmaintained as the base case until you have proven otherwise. If you adopt it, fork it, pin a known commit, and add CI running your own PHP and Symfony matrix.
- What are the security risks of sparse fieldsets and embedded relations in HATEOAS APIs?
- Sparse fieldsets and relation inclusion are client-controlled projections over your domain model, so without strict allow-lists a misconfigured relation can expose fields or relations that were never intended for that endpoint. In an unmaintained package you own that audit yourself. Review every exposed relation and fieldset against an explicit allow-list before shipping.
- How should I test and verify compatibility before adopting gointegro/hateoas-bundle?
- Produce a verified compatibility matrix from composer.json, not the README: PHP version, Symfony major, Doctrine ORM major, doctrine/annotations presence, and symfony/serializer versions. Then write functional tests that assert link structure, embedded resources, pagination, and fieldset negotiation against your real entities. Run that suite in CI on a pinned fork so a PHP minor or upstream release cannot silently break your API.