Can I use TCP in a RESTful service?

REST is using current features of the Web and applying some principles on it to make it more efficient. It uses standard HTTP verbs for communication and take help of its stateless nature.

However, is it possible that a REST service use the TCP protocol for its communication? If yes, then will it violate its principles?

Answers


HTTP is a TCP/IP based protocol. So when you use REST you are already using TCP for communication. But if you want to use REST over pure TCP socket, without HTTP, then no, this doesn't make sense because REST is based on HTTP verbs and headers. Those notions exist only in the HTTP protocol.


Slightly different angle:

1 . Don't use WCF to create REST based services. Use Asp.Net WebAPI.

2 . Just for fun: if you want to use WCF TCP bindings with 'REST' principles in mind, maybe you can create a stateless API based on 'resources' instead of a typical RPC like one.

[ServiceContract]
interface RestApi
{
    Result Get(string id);
    Result Post(string id, Resource resource);
    Result Put(string id, Resource resource);
    void Delete(string id);
}

That way you won't have to define different contract for every service and just adjust your resources for different interactions.

NOTE: I am not suggesting anyone to do this: it's reinventing the wheel. Use WebAPI if you want REST.


As Darin already answered, HTTP is a TCP protocol with some overhead that is exactly what is used in the RESTful definition. So, no, you can't remove the HTTP overhead.

I believe that your question "Can I use TCP for a faster RESTful app?" is related with the question "Why so many websites are using REST if HTTP is slower than pure TCP?".

The truth is: HTTP is indeed slower than the pure binary TCP form, but in most applications, your users will not notice the difference because the overhead is really very small and usually the client will make just a few requests per minute.

For example: GET /posts?userId=5

If this request takes more than a few milliseconds to complete, then the problem is not in the HTTP protocol. The performance problem is related with the network latency, with your server-side code and how you are retrieving data from your database.

On the other hand, if your client code is making thousands of requests per minute, so this single client will notice a performance problem related with the HTTP overhead. In this case, maybe you could batch many operations in a single operation and reduce the amount of network requests.

If a single client really needs to make thousands of requests per minute, then you can think in avoiding REST and to start looking for another approach. Just remember that SOAP can use a TCP binding, but requests also have overheads to parse XMLs. Also, SOAP is stateful and HTTP is stateless. An stateful approach is worse for scalability.


REST is an architectural style (or set of constraints). It just so happens that HTTP can match all of those constraints easily. And on top of that a lot of HTTP/1.1 infrastructure out there is already supporting it: servers, proxies, caches, client libraries, parsers, etc. Something like this:

Can systems be built from scratch be to RESTful and not rely on HTTP? Sure. Coming from the authoritative source on the topic Roy Fielding himself:

A REST API should not be dependent on any single communication protocol.

If you read the article or in fact Roy's dissertation you would realize that if you try to follow all of the constraints you would end up with something that looks and behaves pretty much like the modern HTTP though it would probably lack most of the infrastructure support that HTTP has. Hence the question: Is it worth it?

Also if you take a look at the majority of the RESTful services out there they are very rarely fully REST services. This is why they call themselves "RESTful services", and not "REST services". BTW This site's API comes very close to a full REST implementation.


You can't use other binding except Http for Rest based services. It is due to Rest is a architectural style which is based on certain principle. One of this principle is to take help of stateless protocol of web which is http, also it also want Http words such as Get, Port,Put and Delete to use which are not available at TCP Protocol


Need Your Help

Facebook Like Widget on Fan page, Comment area out of visible area

css facebook facebook-page facebook-widgets

When using the like or send widget on a Fan Page (no mater if you use iframe tag or fbml for it) the overlay for commenting is positioned always to the right. see

How do I import a Swift file from another Swift file?

swift xcode6

I simply want to include my Swift class from another file, like its test