DiveInto Mobile

In my previous article about on-device data caching with HTTP request header values, I alluded to a more complex, but more powerful way to cache data from your REST calls on the client. This, too, provides a free, zero-code caching solution, and again requires your REST API to provide specific HTTP response headers.   This technique involves using the HTTP response header named " ETag ".  While the format of the value isn't specified in the standard, it's generally thought of as an large-ish integer that represents a hash of the REST response payload (or something similar).  The Server Rules (again) As with the Cache-Control header, the server is responsible for sending the ETag value to the client.  The basic idea of the ETag  is for the client to ask the API server "do you have newer data than I do?"  In order to communicate the idea of "newer", the server sends a value is that it is a hash (or something else) unique to this particular pay...

 When designing an app feature that uses data from an API, it's common to have a debate about storing that retrieved data locally on the device.  This can be for performance reasons, or to provide an offline-first experience for the user.  But, before starting to debate the pros and cons of introducing a database layer (or worse, considering storing entire JSON payloads to the device filesystem!), consider this: you might get the on-device storage behavior you want, for free , with no code . Before we go into full infomercial mode here, let me explain.  Whether you realize it or not, when you make an HTTP(S) request in your native Swift or Kotlin code, the server can hint to how the client should handle storing the response, and the underlying network SDK acts on these hints (usually with no indication as to what it's doing!).  In my experience on projects, we don't spend enough time in API design talking about this, and even less time on the frontend team...