Testing OData Services
Aethrix Studio imports an OData V4 service model described in CSDL and exposes it as a normal HTTP service. Everything you can do with an imported REST service then applies: send requests, inspect responses, assert on them, and reuse the operations in Test Automation.
Quickest Scenario
- In API Playground, click Import API definition.
- For Service Type, select
oData - EDM Common Schema Definition Language (CSDL). - For Service Description, enter the metadata address of the service (for example
https://services.odata.org/V4/TripPinService/$metadata) or the path to a local.edmx/.csdlfile. - Step through Authentication (needed only if the metadata endpoint is protected), Analyze, and Application & Service Name, then click Import.
- Select an operation in the service tree — the request opens pre-filled — and click Send.
Tip: the Analyze step fetches and parses the model before asking for names, so an unsupported or malformed model is reported there instead of at the end of the import.
Why an OData service is tested like a REST service
An imported CSDL model is converted to an OpenAPI document internally and then compiled by the same generator that handles OpenAPI. That is why there is no OData-specific editor — you test OData exactly as described in Test a REST Service:
| What you use | Where it comes from |
|---|---|
| Request tab — URL, method, headers, body | Pre-filled from the operation you selected |
| Object Editor — typed payload editing | For entity payloads the model describes with a schema |
| Authentication tab — Basic, Bearer token, OAuth 2.0, API Key, … | OData services commonly require a bearer token |
| Response panel — status, headers, body | The same viewer as any REST response |
For every construct Aethrix degrades or rejects while reading a model — with an example, what you see in Studio, and how likely it is in real services — see Import Diagnostics — Unsupported structures & fallbacks (OData tab).
Compatibility and limits
Only OData V4 is supported. The messages below are quoted from the Studio diagnostics; the codes are explained in Import Diagnostics & Error Codes.
| Situation | What Studio reports | Code |
|---|---|---|
| A V2 or V3 model | OData V2/V3 CSDL is not supported. Only OData V4 CSDL can be imported. Re-export the model from an OData V4 endpoint ($metadata) or convert it to V4. (the detected version is named) | ODA_VER_001 |
| The document exceeds the 1 MB conversion guard | The OData CSDL document is too large (<n.n> MB; limit 1 MB). The OData-to-OpenAPI converter materializes the full model in memory, so very large services (e.g. Microsoft Graph) cannot be imported. Use a narrower $metadata endpoint. | ODA_SIZE_001 |
| The document cannot be parsed | The OData CSDL document could not be parsed. Errors: … | ODA_INIT_001 |
| The model parses but the conversion fails | Failed to convert the OData model to an OpenAPI document: … The model may use constructs unsupported by the OData-to-OpenAPI converter. | — |
Both limits are deliberate rather than defects:
- V2/V3 are rejected because the OData EDM library used for the conversion is V4-only.
- The 1 MB guard exists because the OData-to-OpenAPI conversion materializes the entire model in memory (paths × operations × schemas), so a multi-megabyte
$metadatasuch as Microsoft Graph's would exhaust memory instead of failing politely. The size is checked both before the document is downloaded (against the endpoint's reported length) and again after download.
For a large model, request a narrower $metadata that exposes fewer entity sets.
Using OData operations in Test Automation
Add a Send Request test step and select the imported operation from the drop-down — the same flow as any REST service, described in Send Request Test Step.