Data API builder (DAB) provides REST and GraphQL endpoints over SQL Server, Azure Cosmos DB, PostgreSQL, MySQL, and SQL Data Warehouse. REST endpoints support several HTTP headers that let you control how requests behave. These headers give you precision over updates, caching, and discovering new resources.

If-Match

By default, DAB treats PUT and PATCH as upserts: update if the row exists, insert if not. Sometimes you need stricter semantics. If-Match provides update-only behavior.

If-Match in DAB only supports *. Any other value is rejected.

Example request that only updates if the row exists:

PUT /api/Books/id/1
If-Match: *
Content-Type: application/json

{
  "title": "The Return of the King"
}

If the record exists, you get 200 OK. If not, you get 404 Not Found. This applies to both PUT and PATCH. DAB does not support ETag comparisons or concurrency tokens.

Read the documentation on If-Match.

Cache-Control

DAB can cache query results in memory or in a distributed cache. The Cache-Control request header lets you override cache behavior. This applies only to DAB’s cache, not browsers or CDNs.

GET /api/Books
Cache-Control: no-cache
Accept: application/json

Read the documentation on Cache headers.

Location

When you create a resource with POST, DAB includes a Location header showing the path of the new record. For PUT or PATCH that insert rows, it may be omitted.

• POST inserts: 201 Created with Location.
• PUT/PATCH updates: 200 OK, no Location.
• PUT/PATCH inserts: 201 Created, Location may be omitted.

After creating a book with POST, you will see Location: id/123. Clients can then immediately fetch /api/Books/id/123.

Example POST response:

HTTP/1.1 201 Created
Location: id/123
Content-Type: application/json

{
  "id": 123,
  "title": "New Book"
}

Read the documentation on Location.

Summary

Use If-Match for strict updates, Cache-Control to tune caching, and Location to discover new resources. Together, these headers make your APIs predictable and reliable.