Weave Code
Lodata Laravel Package
flat3/lodata
Lodata is an OData v4 server for Laravel that exposes Eloquent models as standards-compliant APIs. It supports $filter, $select, $expand, $orderby, $top and $skip query options, metadata discovery, and easy model configuration for building rich, queryable endpoints.
The OData v4.01 Producer for Laravel
Frequently asked questions about Lodata
- How do I install flat3/lodata in a Laravel application?
- Install it with Composer using composer require flat3/lodata, then register the package service provider and publish any configuration it ships. After that you register the OData routes in your route files and add per-model OData configuration for each Eloquent model you want to expose. Installation itself is routine; most of the effort goes into deciding which models, columns and relations become part of your entity model.
- Which OData v4.01 query options does Lodata support?
- Lodata supports $filter, $select, $expand, $orderby, $top and $skip, along with $count and $metadata discovery. That covers the core query surface most Microsoft-ecosystem clients use for reads. OData v4.01 is a large specification, so confirm whether the specific features you need, such as lambda operators like any/all, $apply aggregation or delta tracking, are implemented before promising them to a client team.
- Which Laravel and PHP versions does flat3/lodata support?
- Lodata is built for Laravel and integrates through the framework's router and middleware stack, but you should pin PHP and Laravel versions explicitly in composer.json and verify against the matrix you actually run, for example PHP 8.2 or 8.3 with the current and previous Laravel major. Laravel majors move annually, and a protocol package that trails framework support can block your upgrade path. Check the repository's composer.json constraints and test suite before committing.
- How do I expose an Eloquent model as an OData entity set with Lodata?
- You register the model with Lodata and describe how its columns map to EDM properties, what the key is called, and which Eloquent relations become navigation properties. That mapping is your design work rather than something the package infers for you, because it defines the contract your $metadata document promises to clients. Start with the one or two entity sets a named consumer actually needs, then expand from there.
- How do navigation properties and $expand map to Eloquent relationships in Lodata?
- You choose which Eloquent relations are surfaced as navigation properties in the OData entity model, so belongsTo and hasMany relations can then be queried with $expand. Deep expands are expensive and user-controlled, so cap expand depth and limit the relations you expose. Which relations to promote is a schema design decision that strict OData clients will depend on.
- Is flat3/lodata safe to run in production?
- $filter and $expand are user-controlled expression languages, so deep expands and unbounded filters are a denial-of-service vector and can bypass assumptions about field-level access. Enforce authorization per entity set, and per property if the package allows it, and load-test against realistic query patterns. Also check that the package returns structured OData error responses rather than Laravel's default 500 page, since clients expect the former.
- Can I connect Power BI, Excel Power Query or a .NET OData client to a Lodata endpoint?
- That is the main use case: Lodata produces standards-compliant OData v4.01 so strict clients such as Power BI Desktop, Excel Power Query, Microsoft.OData.Client and SAP UI5 can consume it. Because interop bugs surface late and in the client rather than in PHPUnit, validate with the real clients and inspect $metadata early. Ship the metadata document in your first sprint so the consuming team can check the contract.
- Does Lodata support OData writes such as POST, PATCH, DELETE and $batch?
- The package is positioned as a producer over Eloquent models, and its documented strengths are query options and metadata discovery, so treat write support as something to verify rather than assume. OData producer packages in general are stronger on reads than on POST, PATCH, $batch semantics and concurrency handling. Keep your existing JSON API as the system of record for writes until OData write behaviour is proven with your clients.
- How should I test a Lodata OData API?
- Use HTTP feature tests for the query options you expose, then go beyond them with a negative-test suite for malformed $filter and $expand expressions. Test against real clients such as Microsoft.OData.Client, Power BI Desktop or Excel, plus raw $metadata inspection, because that is where conformance problems actually appear. Assert OData-shaped error responses too, not just happy-path payloads.
- Is flat3/lodata actively maintained, and what are the alternatives?
- It is a small, MIT-licensed package with a modest community, so assume a likely single-primary-maintainer bus factor even though the license lets you fork it. Ask about upstream release cadence and confirm your team could patch a fork if needed. The alternatives are building on a general-purpose OData library or exposing a plain REST/JSON API, but if your consumers are Microsoft-ecosystem tools, an OData facade over Eloquent is usually less work than hand-rolling the protocol.
Weaver
How can I help you explore Laravel packages today?