I've created and application and a paginated api which is hooked up to each other. However i'm a bit confused on what is best practice in terms of only showing updated data. For instance if i retrieve data one day and save it into my mobile database. How will the app the next day know that it should make a request and only show that particular data that just has been fetched from the database. Do i need to make somekind of flag or look at createdAt?
When making the request, include either the If-None-Match header with the local resource's ETag or the If-Modified-Since header with the date the local resource was requested.
Configure your server to look for the header and return a 304 Not Modified if the data hasn't changed. That will at least save you some traffic on the responses.
In addition, if the resource data is relatively static, or if the client can tolerate having stale client data, then you can add caching headers to your response. As long as the cached request is valid, the request will never leave your client.
Ideally, you want do design your API to support this where possible. For example, have the request "give me all things in 50 meters" return a list of URIs. Then the API will only have to hit the server for those URIs which are stale.
Related
I'm trying to use etags in order to reduce both my bandwidth and my quota usage but /search returns an new etag even when nothing changed. It also still sends the content if I specify the previous etag in the header.
Is it supported for that api call or am I probably doing something wrong?
Etags are supported by youtube but it depends on what kind of data you are asking
ETags, a standard part of the HTTP protocol, allow applications to refer to a specific version of a particular API resource. The resource could be an entire feed or an item in that feed. This functionality supports the following use cases:
Caching and conditional retrieval – Your application can cache API
resources and their ETags. Then, when your application requests a
stored resource again, it specifies the ETag associated with that
resource. If the resource has changed, the API returns the modified
resource and the ETag associated with that version of the resource. If
the resource has not changed, the API returns an HTTP 304 response
(Not Modified), which indicates that the resource has not changed.
Your application can reduce latency and bandwidth usage by serving
cached resources in this manner.
The client libraries for Google APIs differ in their support of ETags.
For example, the JavaScript client library supports ETags via a
whitelist for allowed request headers that includes If-Match and
If-None-Match. The whitelist allows normal browser caching to occur so
that if a resource's ETag has not changed, the resource can be served
from the browser cache. The Obj-C client, on the other hand, does not
support ETags. Protecting against inadvertent overwrites of changes –
ETags help to ensure that multiple API clients don't inadvertently
overwrite each other's changes. When updating or deleting a resource,
your application can specify the resource's ETag. If the ETag doesn't
match the most recent version of that resource, then the API request
fails.
Using ETags in your application provides several benefits:
The API responds more quickly to requests for cached but unchanged
resources, yielding lower latency and lower bandwidth usage. Your
application will not inadvertently overwrite changes to a resource
that were made from another API client.
https://developers.google.com/youtube/v3/getting-started#etags
I usually scrape Youtube for Videos searches and I just store the Etag that it return. To use the etag, create a header request and put "If-None-Match" equal to your etag value. Note this should be a request header and not appended to the endpoint call. You can also use "If-Match".
Depending on what kind of API you are using, the way of inserting a new value to the request header may differ slightly
We have existed API like
/api/activiation_code
each time, the activiation_code will be different, then server will create a token for this call and return it, usually each call will have different activiation_code which return different token.
Since this API need server to create something so it is designed as POST.
Can we design this API as HTTP GET ?
What is the pro and cons ?
You could design the API to support GET requests, but I would not recommend this. If your API is accessible via a website, a user could accidentally activate an account multiple times since the URL will be stored in the browser's history. Additionally, web crawlers could potentially supply values to your API through the URL if you support GET requests.
POST requests are much better because the information is included in the body of the request, not the URL. Thus, it is much less likely that something will go wrong accidentally.
I'm starting an iOS app that consume a Restful API.
I have control over that API and I'm confusing with the caching policies.
To begin, I only need caching a concrete resoruce, but the problem is that resource can change when I insert new record in the database.
Then, how can I tell to the application "Hey! Make the request only if there have been changes and if not, you get the data from the cache!"
I'm using AFNetworking to make requests..
You'll have to make a decision on either server or client side and build your own protocol.
Example:
You could send the server JSON post request which contains the 'version' of the data you have in the app. On the server-side you will increment the version number each time the data gets refreshed. If the version number does not match at server-side, the server will respond with all new data, else the server responds JSON with 'up to date'
EDIT:
If you are looking for an HTTP response saying that the data is not modified. This is done on server side. You'll have to implement this in the server.
We are currently spiking a Varnish implementation to see if it would be appropriate to sit in front of our Rails application.
We want Varnish to cache the results of an API call and only hit the application when the client's ETag doesn't match the one stored in Varnish or the client's modified date is before Varnish's.
So far, I have not seen Varnish take these values into account.
We only get cache hits when the secondary requests are within the max age.
Is this expected behaviour?
It is the expected behavior, Varnish does not currently revalidated cached content.
There is some experimental work to do what you want, which may or may not end up in Varnish 4.0 (in a few months).
In the meantime what you can do is set an artificially short TTL, and set a grace time equivalent to your desired TTL. With that configuration, when a request comes in Varnish will send an IMS request to the backend (as long as the cached entry has an ETag of course, otherwise it will be a plain request).
The side effect is that Varnish will also send the cached entry if the backend is down or returns 500—this may or may not be what you want.
What I have done is set the hash() function to use the etag provided.
This means that the first request for an object (no etag provided from client) will get the object itself.
Any subsequent request, or any request that provides the header for etag, will get either an object or the 304.
I am optimization my web page by implementing caching, so if I want the browser not to take data from cache, then I will append a dynamic number as query value.
eg: google.com?val=823746
But some time, if I want to bring data from cache for the below url, the browser is making a new http request to server, its not taking data from cache. Is that because of the question mark in URL ?
eg: http://google.com?
Please provide some reference document link.
Thanks in advance.
Regards,
Navin
Use appropriate HTTP headers.
Search of pragma: no-cache and Expires
Browsers may not cache URLs that contain a query string (part after ? ) unless the headers indicate the expiry time explicitly.
Cache policy is not same across all browsers. If you don't specify appropriate headers the results may be even more unpredictable.
Since query strings are used with dynamically generated pages, the browser may take that hint and fire a new request even if the query string is same.
For example, a desktop browser may err on side of caution and fire a new request. On the other hand a mobile browser with aggressive cache policy may pull the page from cache.