- How do I install and set up lomkit/laravel-rest-api in a Laravel application?
- Install it with Composer, publish the package configuration, then define one Resource class per Eloquent model and subclass the package controller to expose search and mutate endpoints. Register the routes in your Laravel route files and confirm your models and Policies are in place. No database changes, sidecar, or separate service is required.
- Which Laravel and PHP versions does lomkit/laravel-rest-api support?
- The 2.x line targets a modern Laravel baseline, with PHP 8.x and Laravel 10/11-era support for v2.23.x. Check the package composer.json for the exact constraints before upgrading, because the 2.23.x line moves quickly. It assumes Eloquent for persistence and Laravel Policies for authorization.
- Why does lomkit/laravel-rest-api use POST /{resource}/search instead of GET query parameters?
- The package sends a structured JSON body to a search endpoint so filters, sorts, includes, limits, and aggregates can be expressed in one consistent query contract. That design is a durable architectural commitment: it affects CDN and HTTP caching, gateway routing rules, API documentation tooling, and client SDK generation. It fits internal, back-office, and first-party client APIs well, but is a weaker fit where public GET semantics and cacheability are contractual.
- Is lomkit/laravel-rest-api affected by GHSA-w87g-c4fx-87gg, and does v2.23.2 fix it?
- The v2.23.2 release references GHSA-w87g-c4fx-87gg and implies remediation for a security issue present in v2.23.1 or earlier, but the release text does not state the vulnerability class or whether configuration or Resource changes are required. Treat upgrading to 2.23.2 and reading the full advisory as mandatory. Also verify whether the fix changes request or response behavior that clients depend on.
- How does authorization work with lomkit/laravel-rest-api Resources?
- The package delegates authorization to Laravel Policies rather than replacing your auth model. Because a single endpoint can expose every declared field, filter, sort, relation, and aggregate, the effective security boundary is the union of your Policies plus the completeness of your Resource declarations. Reviewers must confirm what is intentionally absent as well as what is declared.
- Can I use lomkit/laravel-rest-api for a public-facing API?
- You can, but evaluate the POST-based search contract carefully because public APIs often depend on GET semantics, cacheability, gateway rules, and generated SDK expectations. The package is strongest for internal, back-office, and first-party client APIs where that contract is acceptable. If public caching and standard REST semantics are contractual, hand-written controllers may be a better fit.
- How do filters, sorting, pagination, and relationship includes work in lomkit/laravel-rest-api?
- A Resource declares its available fields, relations, sorts, filters, limits, aggregates, and instructions, and clients send a structured JSON request to the search endpoint. The package applies those declarations to Eloquent queries and returns only what the Resource exposes. This keeps query capabilities explicit but makes Resource declarations the review artifact for API surface area.
- Does lomkit/laravel-rest-api generate OpenAPI documentation automatically?
- The package is designed to provide OpenAPI documentation from your declarative Resource definitions, reducing hand-maintained API docs. Confirm the generated schema covers your declared filters, relations, and aggregates for your version. If you use custom endpoints or middleware behavior, document those separately.
- How hard is it to migrate off lomkit/laravel-rest-api later?
- Migration is possible but non-trivial because the search DSL becomes your public API contract. Moving to hand-written controllers means reimplementing filter, sort, include, and aggregate semantics while preserving client behavior. Plan for a compatibility layer or versioned endpoints rather than a direct controller swap.
- How should I pin and maintain lomkit/laravel-rest-api in production?
- The 2.23.x line is a fast-moving patch series, so pin a reviewed version and make patch review a routine process rather than an optional step. Subscribe to advisories and test upgrades against your Resource declarations and client payloads. Decide who owns Resource declarations as the authorization review artifact before adoption.