Ran into a few tap related things, they are all fi...
# singer-taps
v
Ran into a few tap related things, they are all fixable not certain if it's something that should be brought into the SDK or not though 1. Pagination based on record count. Some apis (clickup https://clickup.com/api ) do pagination based on number of records. There's two approaches that are both probably valid. One is count to the max record count for a page (100 in this case) if the total record count is 100 then go to the next page. Another is to just keep going to the next page until there's 0 records returned 2. Replication keys with pagination. With streams that use a key like data_updated for the replication key, and there's pagination you run into an issue where you may do something like
/api?date_update_greaterthen=1000
(unix time lets say) and you get 100 records, then need to go to the next page. Currently you have to think about do I do the request
/api?date_update_greaterthen=1000?page=2
or do I /`api?date_update_greaterthen=9932` 3. API Rate Limiting - Some APIS have limits. There's a spec I hadn't heard of before that returns headers like
X-RateLimit-Limit
,
X-RateLimit-Remaining
,
X-RateLimit-Reset
. Reset is interesting as it gives you the time at which you can send your next API Requests. There's a spec here https://tools.ietf.org/id/draft-polli-ratelimit-headers-00.html , and a nice walk through of implementations here https://stackoverflow.com/questions/16022624/examples-of-http-api-rate-limiting-http-response-headers