Skip to main content
deleted 6 characters in body
Source Link
NPE
  • 877
  • 4
  • 7

I haven't come across brokerages with Web APIs. In fact, there are several reasons why I think such APIs would be a bad idea for live trading:

  • Security would be a major concern, both for authentication and encryption of sensitive data (perhaps the latter could be addressed by using HTTPS).
  • The HTTP protocol is not designed for transactional data of this sort. It is not all that infrequent that, while browsing the Web, one sees timeouts, "bad gateway" errors and other glitches. Now imagine this happening as you submit an order. You don't know whether the order has made it to the broker, whether it's out on the market, has been filled etc. A specialized protocol can handle this much better.
  • If you lose your connectivity to the broker, it's hard for them to know that and take corrective action on your behalf (e.g. pull all your orders from the market).
  • It is not at all clear what the mechanism for feeding data (e.g. fills) back to you might be.

I think it might be possible to make this work (in a square-peg-in-a-round-hole kind of way), but there are clearly better alternatives.

I haven't come across brokerages with Web APIs. In fact, there are several reasons why I think such APIs would be a bad idea for live trading:

  • Security would be a major concern, both for authentication and encryption of sensitive data (perhaps the latter could be addressed by using HTTPS).
  • The HTTP protocol is not designed for transactional data of this sort. It is not all that infrequent that, while browsing the Web, one sees timeouts, "bad gateway" errors and other glitches. Now imagine this happening as you submit an order. You don't know whether the order has made it to the broker, whether it's out on the market, has been filled etc. A specialized protocol can handle this much better.
  • If you lose your connectivity to the broker, it's hard for them to know that and take corrective action on your behalf (e.g. pull all your orders from the market).
  • It is not at all clear what the mechanism for feeding data (e.g. fills) back to you might be.

I think it might be possible to make this work (in a square-peg-in-a-round-hole kind of way), but there are clearly better alternatives.

I haven't come across brokerages with Web APIs. In fact, there are several reasons why I think such APIs would be a bad idea for live trading:

  • Security would be a concern, both for authentication and encryption of sensitive data (perhaps the latter could be addressed by using HTTPS).
  • The HTTP protocol is not designed for transactional data of this sort. It is not all that infrequent that, while browsing the Web, one sees timeouts, "bad gateway" errors and other glitches. Now imagine this happening as you submit an order. You don't know whether the order has made it to the broker, whether it's out on the market, has been filled etc. A specialized protocol can handle this much better.
  • If you lose your connectivity to the broker, it's hard for them to know that and take corrective action on your behalf (e.g. pull all your orders from the market).
  • It is not at all clear what the mechanism for feeding data (e.g. fills) back to you might be.

I think it might be possible to make this work (in a square-peg-in-a-round-hole kind of way), but there are clearly better alternatives.

added 4 characters in body
Source Link
NPE
  • 877
  • 4
  • 7

I haven't come across brokerages with Web APIs. In fact, there are several reasons why I think such APIs would be a bad idea for live trading:

  • Security would be a major concern, both for authentication and encryption of sensitive data (perhaps the latter could be addressed by using HTTPS).
  • The HTTP protocol is not designed for transactional data of this sort. It is not all that infrequent that, while browsing the Web, one sees timeouts, "bad gateway" errors and other glitches. Now imagine this happening as you submit an order. You don't know whether the order has made it to the broker, whether it's out on the market, has been filled etc. A specialized protocol can handle this much better.
  • If you lose your connectivity to the broker, it's hard for them to know that and take corrective action on your behalf (e.g. pull all your orders from the market).
  • It is not at all clear what the mechanism for feeding data (e.g. fills) back to you might be.

I think it might be possible to make this work (in a square-peg-in-a-round-hole kind of way), but there are clearly better alternatives.

I haven't come across brokerages with Web APIs. In fact, there are several reasons I think such APIs would be a bad idea for live trading:

  • Security would be a major concern, both for authentication and encryption of sensitive data (perhaps the latter could be addressed by using HTTPS).
  • The HTTP protocol is not designed for transactional data of this sort. It is not all that infrequent that, while browsing the Web, one sees timeouts, "bad gateway" errors and other glitches. Now imagine this happening as you submit an order. You don't know whether the order has made it to the broker, whether it's out on the market, has been filled etc. A specialized protocol can handle this much better.
  • If you lose your connectivity to the broker, it's hard for them to know that and take corrective action on your behalf (e.g. pull all your orders from the market).
  • It is not at all clear what the mechanism for feeding data (e.g. fills) back to you might be.

I think it might be possible to make this work (in a square-peg-in-a-round-hole kind of way), but there are clearly better alternatives.

I haven't come across brokerages with Web APIs. In fact, there are several reasons why I think such APIs would be a bad idea for live trading:

  • Security would be a major concern, both for authentication and encryption of sensitive data (perhaps the latter could be addressed by using HTTPS).
  • The HTTP protocol is not designed for transactional data of this sort. It is not all that infrequent that, while browsing the Web, one sees timeouts, "bad gateway" errors and other glitches. Now imagine this happening as you submit an order. You don't know whether the order has made it to the broker, whether it's out on the market, has been filled etc. A specialized protocol can handle this much better.
  • If you lose your connectivity to the broker, it's hard for them to know that and take corrective action on your behalf (e.g. pull all your orders from the market).
  • It is not at all clear what the mechanism for feeding data (e.g. fills) back to you might be.

I think it might be possible to make this work (in a square-peg-in-a-round-hole kind of way), but there are clearly better alternatives.

added 2 characters in body
Source Link
NPE
  • 877
  • 4
  • 7

I haven't come across brokerages with Web APIs. In fact, there are several reasons I think such APIs would be a bad idea for live trading:

  • Security would be a major concern, both for authentication and encryption of sensitive data (perhaps the latter could be addressed by using HTTPS).
  • The HTTP protocol is not designed for transactional data of this sort. It is not all that infrequent that, while browsing the Web, one sees timeouts, "bad gateway" errors and other glitches. Now imagine this happening as you submit an order. You don't know whether the order has made it to the broker, whether it's out on the market, has been filled etc. A specialized protocol can handle this much better.
  • It is hard forIf you lose your connectivity to the broker, it's hard for them to know when you've lost your connection to themthat and take corrective action on your behalf (e.g. pull all your orders from the market).
  • It is not at all clear what the mechanism for feeding data (e.g. fills) back to you might be.

I think it might be possible to make this work (in a square-peg-in-a-round-hole kind of way), but there are clearly better alternatives.

I haven't come across brokerages with Web APIs. In fact, there are several reasons I think such APIs would be a bad idea for live trading:

  • Security would be a major concern, both for authentication and encryption of sensitive data (perhaps the latter could be addressed by using HTTPS).
  • The HTTP protocol is not designed for transactional data of this sort. It is not all that infrequent that, while browsing the Web, one sees timeouts, "bad gateway" errors and other glitches. Now imagine this happening as you submit an order. You don't know whether the order has made it to the broker, whether it's out on the market, has been filled etc. A specialized protocol can handle this much better.
  • It is hard for the broker to know when you've lost your connection to them and take corrective action on your behalf (e.g. pull all your orders from the market).
  • It is not at all clear what the mechanism for feeding data (e.g. fills) back to you might be.

I think it might be possible to make this work (in a square-peg-in-a-round-hole kind of way), but there are clearly better alternatives.

I haven't come across brokerages with Web APIs. In fact, there are several reasons I think such APIs would be a bad idea for live trading:

  • Security would be a major concern, both for authentication and encryption of sensitive data (perhaps the latter could be addressed by using HTTPS).
  • The HTTP protocol is not designed for transactional data of this sort. It is not all that infrequent that, while browsing the Web, one sees timeouts, "bad gateway" errors and other glitches. Now imagine this happening as you submit an order. You don't know whether the order has made it to the broker, whether it's out on the market, has been filled etc. A specialized protocol can handle this much better.
  • If you lose your connectivity to the broker, it's hard for them to know that and take corrective action on your behalf (e.g. pull all your orders from the market).
  • It is not at all clear what the mechanism for feeding data (e.g. fills) back to you might be.

I think it might be possible to make this work (in a square-peg-in-a-round-hole kind of way), but there are clearly better alternatives.

added 128 characters in body
Source Link
NPE
  • 877
  • 4
  • 7
Loading
added 143 characters in body
Source Link
NPE
  • 877
  • 4
  • 7
Loading
Source Link
NPE
  • 877
  • 4
  • 7
Loading