The documentation specifies that all resources should have etags, but I find that multiple resources that don’t e.g.
Is this something that is being worked on?
Specifically, in the cases where the API does not return an etag, the etag is marked as ‘read-only’ in the documentation.
Yes, it is something that is being worked on.
Ultimately, every resource will return an etag. As a client, if you make a request and supply an etag that you received previously, then the api will immediately tell you if the resource hasn’t changed, with no body obviously.
If it has changed, the resource will be returned, of course with a new etag.
This handling would be particularly important for bandwidth reduction scenarios, such as mobile.
We’re just not quite there yet with the implementation, but was included in our internal design guideline for our new API platform, which is why you see it (mostly) included.
Hi @MArkWilliams, I don’t mean to bump an old thread, but seeing as you linked to this yesterday, do you have any rough ETA on when we can expect wider roll out of ETags in the API? Specifically I’m interested in ETags in the filingHistoryList resources to see if there’s been any new filings or any old filings have been updated.
Thanks, Kevin
No we don’t, but you maybe more interested in the streaming APIs that will be available in the next few weeks.
These will publish all the changes to filing history and company details (with more to come).
Keep an eye on the forum for more details very soon.