Originally Posted by
WannaTheater
DISCLAIMER: Techno geek speak to follow:
AB Dada seems to be scraping data from the resulting html generated from a web call… basically extracting which seats are available and which are not, which is readily available in the html. Pretty easy for someone with software experience. Depending on volume, this may not be sustainable for a production environment that is doing this thousands if not millions of times (think every seat alert customers set through EF, probably polling at a set rate). So they rely on API calls through a pay subscription service, which allows for millions of searches direct to underlying seat availability database(s). Possibly something happened to the API results EF is now getting, which is incorrectly showing MCE seats which are actually available as occupied. If the source of the information to EF is not correct, then EF’s hands are tied, and they are at the mercy of the API developers of whatever service they are using. But if the API data is correct, then I would assume EF no longer has developers, since JSON parsing is generally not difficult.
Some quick googling identifies some of the potential travel systems that EF could be using, along with published APIs, but it seems like access is restricted to actual travel companies/brokers, and not to individual like myself. If anyone with access to the underlying travel databases would like to PM me API keys/secrets, I’ll gladly take a look. 🙂
I could absolutely set up the same (and set it up on a DO droplet so it works all the time and so they don't know it's me), but yes, it's a very heavy call, and subjecting AA's servers to that every few minutes will probably lead them to kill the interface for everyone.
From what I can tell, nobody actually works at Expertflyer, they're just sent over by RV to keep it running. The developers there (at RV) seem to be more frontend oriented, working on their other websites, hence why it's now very broken (and not fixed quickly).