- What is RESTQL for Laravel and what does it do?
- RESTQL is a Laravel package that exposes Eloquent models as flexible REST endpoints. It provides a query language for selecting fields, filtering, sorting, paginating, and including relationships, so you can build JSON APIs with less boilerplate. It is a read-query layer rather than a full API platform.
- How do I install RESTQL in a Laravel application?
- Install it with Composer using composer require gregorip02/restql, then publish any configuration the package provides and map your models or resources. Because the package has not seen a release since 2021, verify PHP and Laravel constraints with composer why-not before adopting it. A contained read-only pilot is safer than rolling it out across all endpoints.
- Which Laravel and PHP versions does gregorip02/restql support?
- The public overview does not list supported Laravel or PHP versions, and the last release cadence points to 2021. Check the composer.json constraints and run composer why-not against your target stack. Expect possible incompatibility with modern Laravel releases and budget for a fork or patched dependency if a spike succeeds.
- How does RESTQL handle authorization and policies for models and relationships?
- Authorization is not described in the overview, so treat it as your responsibility rather than a built-in guarantee. Put RESTQL routes behind Laravel authentication, policies, and row-level scoping, and review the package source to confirm how model and relationship access is resolved. A query-resolution layer can widen the attack surface for authorization bypass if policies are not enforced per model, field, and relationship.
- Can I limit relationship depth, field selection, and pagination in RESTQL?
- The package's selling point is client-driven field selection, filtering, sorting, pagination, and relationship includes, but the overview does not guarantee built-in depth or field limits. You should enforce allowlisted relationships, maximum depth, pagination caps, field limits, rate limiting, and caching at the application or gateway layer. Load test realistic graph shapes before production because relationship expansion can cause N+1 queries and large payloads.
- Is RESTQL a good alternative to Laravel API Resources or GraphQL?
- RESTQL is best treated as a candidate read-query accelerator, not a strategic replacement for Laravel API Resources, GraphQL, or a separate BFF. It fits Laravel applications already using Eloquent that need client-driven read queries without hand-building every filter. If your architecture already standardizes on API Resources or GraphQL, adding RESTQL increases surface area for little gain.
- What license does RESTQL use and can I use it in a commercial product?
- RESTQL is distributed under GPL-3.0, which requires legal review before product distribution. GPL obligations can affect how you ship or distribute a commercial Laravel application, so confirm your distribution model with legal counsel. Do not sequence adoption ahead of a license decision.
- Is gregorip02/restql actively maintained and safe for production?
- Maintenance risk is high: the last release was in 2021, the project has roughly 127 stars, and it appears to be single-maintainer. Plan for internal ownership, upgrade blockers, and the possibility of forking, patching, or replacing the package. Community support is thin and there is no vendor SLA, so rely on source review, tests, and internal documentation.
- How do I test RESTQL endpoints and prevent N+1 query issues?
- Add contract tests that compare RESTQL responses against your existing controller or API Resource output before switching endpoints. Test authorization per model, field, and relationship, and assert that disallowed relationships and excessive depth are rejected. Include performance tests with realistic relationship graphs to catch N+1 queries, large payloads, and memory pressure.
- Can RESTQL handle API versioning and contract testing?
- The overview does not document native API versioning or contract-testing support, so plan to handle versioning through route prefixes or separate endpoint groups. Contract tests are still valuable: capture expected JSON shapes and run them in CI against a pinned package version. Keep the old endpoint available for rollback until parity is proven behind a feature flag.