start by reading the terms of use for any of the sites you intend to poll.
then plan on at least one of said sites blocking your service.
think over whether you want to be invested in an arms race, or if you have any interest talking directly with the companies whose services you would monitor.
tl;dr think about the non-code parts very carefully before taking any architectural advice you get here and running with it.
I did wonder if an api would be polled so heavily.
To push data, things like Outlook mobile keeps a TCP Keep Alive connection open from the server to the phone and pushes data to the phone, so when an email arrives at the server, the phone is updated almost immediately. The TCP Keep alive can be a bit of nuisance for some firewalls though.
So like you say, a good idea to check any terms the site might have, otherwise a denial of service could occur.
I don't believe I'd end up dossing the service as I would be querying the API in the same way their own website and mobile app do.
Considering also I expect my service to be used lightly, my traffic would probably be minimal compared to the their regular one.
But in any case I was thinking about caching/grouping the request to optimize that.
I dont know how the API works or what's behind it, so sometimes like others have pointed out, repeated polling of an api, could be causing a DOS situation and I just mentioned how the TCP Keep Alive could help with an API that could push data.
it's just a single site, not many, it's very specific.
what I have used for my purpose is the same REST API that their website (and possibly mobile app) use to pull the availability
then plan on at least one of said sites blocking your service.
think over whether you want to be invested in an arms race, or if you have any interest talking directly with the companies whose services you would monitor.
tl;dr think about the non-code parts very carefully before taking any architectural advice you get here and running with it.