You don't have to have EMDN-Tap running to use TD. EMDN-Tap is just a way to update the prices in the
local database.
Technically, TD gets all of it's data from "data/TradeDangerous.prices" which is a human-readable file (also human editable).
The "local database" is a machine-readable form of the data. If you change the .prices file and then run trade.py, it rebuilds the db file - this is an efficiency optimization, a "cache". Open "TradeDangerous.prices" in an editor, fly the game, dock at a station, compare the entry for the station in .prices against the game, make your changes, save, and trade.py will pick up the changes next time you run it.
If you instead go to a web-based API, you're going to experience a lot of hurt unless that API essentially does all the work for you.
The problem that TD is trying to solve is officially described as an "NP Problem" [
http://en.wikipedia.org/wiki/NP_(complexity)]. Most of the other profit calculators are approximating a result set by using a tweak of the rules.
For example: You have a Lakon Type 9, 228 capacity, 20,000 credits at StationA. The most profitable possible trade is ItemA StationA->StationB for 8000cr each profiting 1100cr/ton. The least profitable trade is ItemZ StationA->StationC for 85cr each profiting 55cr/ton.
Some calculators only bother to check highest profitability. ItemA wins, meaning you can make a maximum of 2200cr.
Others will try and fill up your hold with other trades you can make StationA->StationB, but after buying the gold you only have 4000cr left. The problem with this approach is that the individually most profitable items are usually the most expensive. So they perhaps boost you to 2800cr for a run.
You can comfortably afford a full load of ItemZ. 228 x 55cr profit = 12540kcr profit; that's 10k more than the obvious choices.
I also documented
here another more complex example of how TD works harder for your earnings
In order to do this efficiently, you need to have a lot of data to form constraints with early on. Fundamentally, one of the things that makes a problem NP is that for some portion of the problem where you can't know what data can be discarded in advance - you *have* to do a computation with it to *prove* that it's not required: If I ask you to give me the largest number in this list (1,2,3,4,5) that's easy, but if I ask you which number in this list uses the most pixels (1,2,3,4,5)
in helvetica you can't answer that without doing some work.
If you try and use TD from a web-based API you're going to have to pull all of the data from the API in order to start forming constraints; you can't specify which stations you want data for in advance.
You could probably cache the data locally and only refresh it periodically, but you're still going to be hammering the API.
If you're ok with that, you can probably work that way, although I think the guy providing the API might feel different about that fairly quickly