Weave Code
Hateoas Bundle Laravel Package
fsc/hateoas-bundle
Symfony bundle that adds HATEOAS hypermedia links to your API responses. Define relations and links with annotations, integrate with JMS Serializer and Symfony routing, and expose discoverable HAL/JSON-LD resources so clients can navigate your API at runtime.
Please use https://github.com/willdurand/hateoas and https://github.com/willdurand/BazingaHateoasBundle instead.
Frequently asked questions about Hateoas Bundle
- Is fsc/hateoas-bundle compatible with Laravel?
- No. Despite being catalogued alongside Laravel packages, fsc/hateoas-bundle is a Symfony bundle built on Symfony-only contracts: a Bundle subclass, a DependencyInjection extension with a configuration tree, compiler passes, RouterInterface and RequestStack. None of those integration surfaces exist in Laravel, so there is nothing for a Laravel application to autoload or boot. Its output layer is also a JMSSerializerBundle event subscriber, which assumes a serializer Laravel does not ship.
- What does fsc/hateoas-bundle actually do?
- It adds HATEOAS hypermedia links to API responses, letting you declare relations and links with annotations and expose discoverable HAL or JSON-LD resources so clients can navigate your API at runtime. Link generation is driven by the Symfony router, and serialization is handled through JMS Serializer. The reusable idea is small: declarative relation metadata, a Link value object, router-driven URL generation and HAL-style _links emission.
- How do I install fsc/hateoas-bundle, and should I add it to composer.json?
- You should not add it to a Laravel composer.json. In its native Symfony context it is installed with Composer and registered in the kernel with its DI extension, but in a Laravel stack it would install code that can never boot. The repository README itself now points developers to willdurand/hateoas and willdurand/BazingaHateoasBundle instead, which tells you the maintainers consider it superseded.
- Is fsc/hateoas-bundle still maintained?
- No. It is Symfony 2.x and 3.x era code from roughly 2013 to 2016, with zero dependents, which means no downstream consumers exercising it, no bug reports and no community patches. There is no CVE or security response process around it. Treat any code you lift from it as code your team now owns and maintains.
- What are the best Laravel alternatives for HATEOAS and HAL links?
- For a Laravel application the idiomatic choices are league/fractal with spatie/laravel-fractal plus a custom HAL serializer, or JSON:API via laravel-json-api. With Fractal you define the relation vocabulary yourself and get transformers and includes without an abandoned dependency. If your organisation is Symfony-first, API Platform supersedes this bundle entirely and is actively maintained, but it is not applicable to Laravel.
- Can I use fsc/hateoas-bundle with JMS Serializer inside a Laravel app?
- Technically you could pull JMS Serializer into a Laravel project, but the bundle's serialization behaviour is delivered as a JMSSerializerBundle event subscriber, so you would be hand-wiring Symfony bundle plumbing rather than using Eloquent API Resources. That path is unsupported and untested against modern Laravel or PHP versions. Reimplementing the handler against native API Resources or a Fractal layer is the lower-risk option.
- How much work is it to port fsc/hateoas-bundle to Laravel?
- It is a build, not an install, and realistically a two to four week port. You need a ServiceProvider with publishable config, PHP 8 attributes replacing doctrine annotations, Illuminate\Routing\UrlGenerator replacing RouterInterface, a rewritten serializer handler over API Resources or Fractal, and a content-negotiation middleware to replace Symfony's format listener. The good news is the conceptual surface is small, on the order of a few hundred to about a thousand lines.
- Which PHP and Symfony versions does fsc/hateoas-bundle support?
- It targets the Symfony 2.x and 3.x era and is likely pinned to jms/serializer 0.x or 1.x with PHP 7.x or lower constraints, so it will not install cleanly on a modern PHP 8 stack. If the original used annotations, it also pulls in doctrine/annotations, which is a hard fork in the road versus attributes. Validate the original composer.json constraints before committing to anything.
- How does fsc/hateoas-bundle handle link generation and content negotiation?
- Link URLs are generated through Symfony's RouterInterface and the current request comes from RequestStack, so the bundle only knows how to build routes in a Symfony kernel. Content negotiation is inherited for free from Symfony's format listener, which inspects the Accept header and selects the format. In Laravel you would need both replaced, with a middleware handling Accept-header negotiation and the URL generator producing links.
- Is fsc/hateoas-bundle safe to run in production, and how would I test a port?
- Running it in production is not advisable: it is unmaintained, has no dependents, no bug reports and no security response process, so any vulnerability becomes yours. If you port the concepts into an internal Laravel package, cover it with feature tests that assert the emitted _links blocks, the relation names and the negotiation behaviour for each Accept header. That gives you regression safety the original never had and keeps the hypermedia contract explicit.
Weaver
How can I help you explore Laravel packages today?