If you want to pull non-consensus agreed data from the web and you are ok with it possibly being wrong(sometimes this is harmless) you may want to search the forums for the project that was doing something with the websockets api. (Found it Non replicated HTTPS outcalls looks like you’ve already seen it.) They were relaying the request outside of the ic via a websocket and getting it back via the socket.
The speed of light plus consensus just makes some things hard.
I’ll guess I’ll add some color for the casual observer as to WHY you can’t just send a call from one replica and continue on. When you use this web socket solution the intercanister call captures the request data in state and the remote canister sends it back as an IC message so that it is in state. Therefore, it can be played back. You wouldn’t be playing back the actual request(the data may have changed…or the device shut down). You are playing back the canisters commitment to an input and output. That data is only as good as the trust you give that service.
The internet and web2 are just inherently non-deterministic. The http outcalls feature layers on a “pretty good” system for eliminating that non-determinism, but every time you make one you are injecting inbound and unknown trust assumptions into your code. You may think that checking Binance and Coinbase eliminates the possibility of getting a wrong ETH price, but it does not. There is a non 0 chance that they both screw up at the same time(maybe some commonly relied on software has a freak bug one day) and then poof you just sent a couple orders of magnitude more tokens than you should have. So check six services…you can get the chance really low, but the only way to really eliminate it completely is for there to be more at stake for the service provides for being wrong then you have on the line. It is a tough nut to crack.