TCP Fast Open: expediting web services [LWN.net]

TCP Fast Open: expediting web services

Posted Aug 2, 2012 20:42 UTC (Thu) by dlang (guest, #313)
In reply to: TCP Fast Open: expediting web services by tialaramex
Parent article: TCP Fast Open: expediting web services

you are making the assumption that the RESTful web service is read-only.

How can you do a RESTful web service where the client is sending information to the server without causing these sorts of problems?

to post comments

TCP Fast Open: expediting web services

Posted Aug 3, 2012 2:02 UTC (Fri) by butlerm (subscriber, #13312) [Link]

The normal technique is to mark all non-idempotent requests with a unique id, and keep track of which ones have already been processed. That is practically the only way to get once-only execution semantics.

This could presumably be done (up to a point) at the transport layer with TCP Fast Open by having the initiating endpoint assign a unique identifier to a given user space connection request, attaching the identifier as a TCP option, caching the identifier for some reasonable period on the target endpoint, and throwing away SYN packets with connection identifiers that have already been satisfied. The more general way to do that of course is to do it at the application layer, in addition to anything the transport layer may or may not do.

TCP Fast Open: expediting web services

Posted Aug 3, 2012 15:35 UTC (Fri) by epa (subscriber, #39769) [Link] (1 responses)

I thought that part of making a RESTful web service was deciding which operations are read-only and which affect the state; and splitting them into GET and POST requests accordingly.

TCP Fast Open: expediting web services

Posted Aug 3, 2012 21:16 UTC (Fri) by dlang (guest, #313) [Link]

That depends on how you define REST

many groups make everything a GET request, especially for APIs that are not expected to be used from browsers, but rather called from other applications, especially in B2B type situations.