| |||||||||||||
TCP Fast Open: expediting web servicesTCP Fast Open: expediting web servicesPosted Aug 2, 2012 16:11 UTC (Thu) by man_ls (subscriber, #15091)In reply to: TCP Fast Open: expediting web services by epa Parent article: TCP Fast Open: expediting web services That is not required in the RFC, and I am not sure that restful, stateless web services would be even possible. After all, web services are supposed to change state in the server; otherwise what is the point?
(Log in to post comments)
TCP Fast Open: expediting web services Posted Aug 2, 2012 16:32 UTC (Thu) by tialaramex (subscriber, #21167) [Link]
Maybe I don't understand. Internally we have a great many RESTful web services which all work roughly like this:
The client asks if this particular combination of data (provided as GET query parameters) is found in the database overseen by that web service. The server looks in its database (e.g. maybe it's the collection of all voter registration records for a particular country) and if there is a matching record it replies saying what was found and where.
You can run that same request again and get the same exact answer and running it many times or not at all changes nothing‡ so that seems to meet your requirement entirely.
‡ In practice some of the services do accounting, they are incrementing a counter somewhere for every query run and then we use that counter to determine the payment to a third party for the use of their data. But this is no greater deviation from the concept than the usual practice of logging GET requests and anyway most of the services don't do that.
TCP Fast Open: expediting web services Posted Aug 2, 2012 20:42 UTC (Thu) by dlang (✭ supporter ✭, #313) [Link]
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?
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]
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 (✭ supporter ✭, #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.
|
|||||||||||||