implementing HTTP reliability

2.1k views Asked by At

My application is a desktop client and a web API application. I am writing both programs.

Does the internet discard old requests? Does it make a difference if it is just an old request or a duplicate request?

Is retrying HTTP requests the only way to ensure almost complete end-to-end reliability over HTTP or is there someway to achieve SOAP-level reliability by just setting arguments or headers without using SOAP? My app is not using SOAP, just Python standard library synchronous requests (multi-threaded).

1

There are 1 answers

1
GolezTrol On

HTTP is usually not the most ideal option for this. You send a single request after which the connection is broken.

Then again, HTTP uses TCP. TCP will allow you to wait for a response that will tell you if the server has received all information as opposed to UDP which is fire & forget.

So the TCP layer is secure enough. HTTP is a request/response protocol. After the response, the connection is closed. There are features for 'keep-alive' connections, but these don't work on all servers. You typically can't rely on that.

If HTTP is the right protocol depends on the situation:

If

  • application only sends a request once in a while
  • server doesn't need to send information back on its own, but only in response to a request
  • others ports/protocols are no option due to firewall settings

then

HTTP is the right way to go. If any of the statements above are false, you might better use a different type of TCP protocol.