Basic Principles

Caching

The ressources, that are returned by the API, line real estate objects, short list entries, saved searches, will expire , so we discourage caching on the client side. To minimize response time and network traffic the API supports HTTP Etags and datestamps. If your network library has Etag and datestamp support, we recommend using If-None-Match- or If-Modified-Since-Headers. If one of the clients Etag matches the resource on the server or the resource was not updated since the last request, it will send an empty reply with a 304 Not Modified status. If you have both options of using If-None-Match or If-Modified-Since, we recommend using If-None-Match (Etags).

Note: The here described ETag handling applies to conditional GET requests, it is not intented for conflict detection (concurrent write operations like PUT).

We offer ETag support for the following ressources:

  • expose
  • shortlistEntry

in planning:

  • Savedsearch

Used status codes

Resource entity exists and has no changes (equal ETag hash)

"304 Not modified" (No content entity.)

Resource entity does not exist

"404 Not found"

Resource entity exists and has changes (different or new ETag)

"200 OK" (With normal content entity and additional caching information headers.)