Weave Code
Core Laravel Package
api-platform/core
API Platform Core is an easy-to-use, powerful PHP library for creating hypermedia-driven REST and GraphQL APIs. Integrate it with Symfony, support JSON-LD, Hydra, OpenAPI, JSON:API, HAL, and Problem Details, and build fully featured API-first projects in minutes.
Build a fully-featured hypermedia or GraphQL API in minutes!
Frequently asked questions about Core
- Can I use api-platform/core in a Laravel application instead of Symfony?
- Yes, but not natively. The api-platform/laravel package is a compatibility layer that lets the Symfony-oriented core run inside a Laravel application. The API layer becomes a distinct subsystem with its own serializer, conventions, and debugging surface, so plan for that architectural cost. It is a legitimate approach, but for a Laravel-centric team it is a paradigm import rather than a native fit.
- Does api-platform/core work with Eloquent models or only Doctrine?
- The mature API Platform integrations are built around Doctrine ORM and ODM. An Eloquent-first team either introduces Doctrine alongside Eloquent or writes custom state providers, and writing custom providers is real engineering work rather than configuration. Treat the persistence layer as a primary feasibility gate before adopting the package. Confirm whether you need Doctrine, custom state providers, or both.
- Which Symfony and Laravel versions does api-platform/core 4.4 support?
- The 4.4 line requires symfony/* ^7.4 || ^8.0 and explicitly dropped Symfony 6.4 and 7.0 through 7.3. Laravel's own dependency constraints can lag Symfony's floor, so run a composer why-not check against your target Laravel version before committing. Pin a stable 4.4.x release and verify version metadata against Packagist rather than relying on feed data. A Composer conflict here blocks the entire initiative.
- How do I install api-platform/core in a Laravel application with Composer?
- Install api-platform/core together with api-platform/laravel using Composer, targeting PHP 8.2 or later and pinning a stable 4.4.x release. Check dependency conflicts against your Laravel version first, then follow the documented Laravel integration path. Introduce it behind a new route prefix rather than replacing existing routes. Prove persistence and authentication in a small spike before expanding.
- Is api-platform/core overkill for a simple Laravel REST API?
- Possibly. API Platform Core is metadata-driven and derives routing, serialization, validation, security, and documentation from resource definitions, which is a lot of machinery for basic CRUD. A hand-rolled Laravel API may be simpler if you only need straightforward JSON endpoints. The payoff comes when you need hypermedia formats, OpenAPI, and GraphQL generated from a single resource definition, so decide based on actual consumer requirements.
- What API formats does api-platform/core support out of the box?
- It natively supports JSON-LD, Hydra, HAL, JSON:API, Problem Details, OpenAPI v2 and v3, and GraphQL. Built-in HATEOAS hypermedia and content negotiation are part of the core design. This lets you generate multiple representations from one resource definition instead of hand-rolling each format. Check that the specific format your consumers need is covered by your pinned version.
- How do I secure API Platform endpoints with Laravel Sanctum or Passport?
- Authentication and authorization are the least certain integration point when running API Platform inside Laravel. Laravel's Sanctum or Passport guards need to be wired into API Platform's security expressions, and that wiring should be proven in a spike rather than assumed. Test both authentication and per-resource authorization paths before relying on them. Document the security model because it spans two frameworks.
- Does API Platform Core generate GraphQL endpoints automatically?
- Yes, API Platform Core can generate GraphQL endpoints from the same resource definitions used for REST. However, GraphQL roughly doubles the API surface you must secure and load-test. Adopt it only if GraphQL is an actual requirement rather than an aspiration. If you do not need it, disabling it reduces operational and security overhead.
- What are the maintenance and upgrade risks of api-platform/core?
- The project is mid-flight into 5.0 with breaking changes already merged, including removal of deprecated APIs and replacement of the legacy PropertyInfo type system. The Doctrine filter layer is being actively rewritten, with legacy filters deprecated in favor of standalone filters; an api:upgrade-filter codemod reduces but does not eliminate that risk. Serializer edge cases around nullable collections, enum backing types, union-typed IRI collections, and IRI type confusion also indicate a still-settling type-handling surface. Assign a quarterly upgrade owner and verify package provenance and version pinning against Packagist.
- How should I migrate an existing Laravel API to api-platform/core?
- Do not rewrite the existing API. Introduce API Platform behind a new route prefix and migrate resource by resource, starting with a single read-only collection plus item endpoint backed by your chosen persistence adapter. Prove authentication, authorization, and serialization behavior on that first resource before expanding. This incremental approach keeps existing consumers working while you validate the integration.
Weaver
How can I help you explore Laravel packages today?