Lesson 3 of 5
OData and REST APIs for testers
10 min
Listen to this lesson
OData is a standard protocol for REST APIs. SAP uses it for the services behind Fiori apps and for most released SAP S/4HANA APIs that other systems call. Testing an OData API means sending HTTP requests and checking the responses, which sounds technical but follows a handful of simple rules.
The vocabulary
| Term | Meaning | Contoso example |
|---|---|---|
| Service | A published API with a root URL | The sales order API, for example /sap/opu/odata/sap/API_SALES_ORDER_SRV |
| Metadata | The machine-readable description of entities, fields and types | $metadata on the service root |
| Entity set | A collection of records of one kind | Sales order headers |
| Entity and key | One record addressed by its key | Sales order '1000457' |
| Navigation property | A link to related records | From the order header to its items |
OData terms with a sales order example.
Query options
Read requests can be shaped with system query options appended to the URL. The most useful for testers are $filter (conditions, such as sold-to party equals Great Lakes Fleet Services' number), $select (only certain fields), $expand (include related entities, such as items), $top and $skip (paging), $orderby (sorting) and a count option to get the number of matching records. Testing these options is part of testing the API: does $filter on a date include the boundary, does paging return every record exactly once?
Remember that an API returns only what the calling user is allowed to see. A technical user for an integration with a warehouse system may be restricted to plant 1720. If that user reads orders for plant 1710 and gets an empty list, that may be correct behavior, not a defect. Always test APIs with the same technical user and authorizations the real integration will use.
HTTP methods and status codes
| Request | Purpose | Success code | Common failures |
|---|---|---|---|
| GET | Read an entity or a filtered list | 200 OK | 404 not found; 403 not authorized |
| POST | Create an entity, such as a sales order | 201 Created, with the new entity in the body | 400 bad request with a business error message |
| PATCH / PUT | Change an entity | 204 No Content (or 200) | 412 precondition failed when the record changed in between |
| DELETE | Delete an entity, where allowed | 204 No Content | 405 or 400 when the business object cannot be deleted |
SAP Gateway protects changing requests with a CSRF token: a client first reads a token (by sending a GET with a header asking to fetch it) and then sends it with the POST, PATCH or DELETE. A test client that skips this step gets a 403 even with full authorizations. Knowing that saves a wasted authorization defect.
- GET with fetch headerThe client asks SAP Gateway for a CSRF token.
- Token returnedThe response header carries the token for this session.
- POST with tokenThe create request for the sales order sends the token back.
- 201 CreatedThe new order comes back in the body; display it in SAP to compare. Skip the token and the result is 403, whatever the user's authorizations.
Exploring APIs on the SAP Business Accelerator Hub
The SAP Business Accelerator Hub (api.sap.com) documents SAP's published APIs, including those for SAP S/4HANA, with their entities, fields and operations. For many APIs it offers a sandbox: after signing in you can send requests to an SAP-hosted test system with an API key and see real responses. That is a safe place to learn an API's shape before testing against Contoso's QAS. Inside your own system, the SAP Gateway Client (/IWFND/GW_CLIENT) lets authorized users execute OData requests directly.
Comparing a response with expected data
- Check the HTTP status first. A 200 with an error message inside is still worth a defect.
- Check the key: is this the record you asked for?
- Compare each field you care about with the expected value from the source document, for example the order's sold-to party, net value and currency for order 1000457.
- Mind the formats: OData V2 returns amounts as strings and dates in a special format; compare values, not text.
- For lists, compare the count with an independent count and check that paging does not duplicate or skip records.
- For creates, display the new document in SAP and compare it with what you sent.
What would you do?
A tester calls Contoso's sales order API to create an order and gets a 403 Forbidden. The same user can create orders in Fiori. What should the tester check first?
- OData services expose entity sets addressed by keys, with metadata describing fields and types.
- Use $filter, $select, $expand, $top, $skip and $orderby to shape reads, and test them as API behavior.
- Check status codes first, then field-by-field values against independent expectations.
- Explore APIs and sandboxes on the SAP Business Accelerator Hub; use the Gateway Client in your own system.
Check your understanding · not graded
Lesson check
1. Which query option includes related entities such as order items in the response?
2. What status code typically confirms a successful create via POST?
3. Where can testers explore SAP's published APIs and try them in a sandbox?
4. What does $metadata return?