4 ms·
Yes and no. Should you keep using HTTP calls for adding an item to a cart? Possibly. Should you use HTTP calls to communicate between services, let's say, to po
by kh_hk 8y ago
Yes and no. Should you keep using HTTP calls for adding an item to a cart? Possibly. Should you use HTTP calls to communicate between services, let's say, to poll a resource every second and know if a worker has finished, when there are better systems and there's good enough technology available to support a higher throughput? Not so much.
- icebraining 8y agoPolling every second would be wasteful; you can just make an HTTP request and hold the connection open until it's finished. Or just pass an URL, and let the other side call you. (That's assuming HTTP, which btw is not the only protocol which can implement REST constraints)
- kh_hk 8y agoThen you are dealing with client timeouts or the fact that a lot of endpoints do not support url callbacks (for good reasons) or maybe clients that cannot be called back (for good reasons too). Cannot say much about REST constraints outside of HTTP so excuse my ignorance on that. But I think it was clear the parent was referring to HTTP, or most possibly, GET and POST HTTP calls returning JSON.
- icebraining 8y agoYou always have to deal with timeouts and other network issues, regardless of protocol. Rather than retry every second, you retry on timeout.
- kh_hk 8y agoAnd yet most HTTP APIs are going to give you a response with an status instead of holding it. I guess because it's much easier to implement and also assumes less on the consumer part. Then there was Comet and what resulted from that, websockets and server side events.
- bduerst 8y agoSo in summary - HTTP calls for front-end, but not back-end to back-end services?
- kh_hk 8y agoI wouldn't be super quick on drawing the front-end and back-end distinction. A front facing interface using sockets could (depending on how flexible we are with terminology of course) be considered front-end too. And I think that's the entire point of the article. I have seen huge benefits, performance being one, communicating using ZMQ (at the cost of complexity and reliability). A worker, running on your computer, consuming data fed through a socket from a broker, running on your server.
- lotyrin 8y agoNot exactly. Transactional CRUD (post a form, submit an email, add to cart) is pretty well adopted and standardized as HTTP, so probably use that (even backend to backend, if the contract fits CRUD resource semantics). RPC (non-CRUD interactions) or streaming updates (e.g. a spinner in a app representing a pending job) or low latency (chat messages / presence status, etc.) don't really fit to HTTP requests so great (requiring e.g. polling) so you should look at alternatives (probably something proxied over a websocket in the case of a browser front-end app).
- dragonwriter 8y ago> Should you use HTTP calls to communicate between services Yes, it's mostly fine for that. Not always ideal, sure. > let's say, to poll a resource every second and know if a worker has finished No, you generally shouldn't poll every second. You should POST a subscription and then the other end should POST you a notification. If you are in a situation where you need to poll instead of subscribing and waiting, then, maybe use HTTP long polling, maybe poll less frequently than every second, maybe use something other than HTTP, but in any case you are in a suboptimal circumstance. (Of course, whether you should use HTTP as a transport protocol is orthogonal to whether or not you should use a REST architectural style.)