0

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).

H2ONaCl
  • 10,644
  • 14
  • 70
  • 114

1 Answers1

0

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.

GolezTrol
  • 114,394
  • 18
  • 182
  • 210
  • I would say that all three of your points probably apply. I want the desktop app to promise reliability or to just say "the system is down for maintenance". The client is not a browser so I don't think it is a nice design to have a human decide to retry. – H2ONaCl Feb 08 '11 at 13:45