Can I use TCP in a RESTful service?

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

Short Answer

No it will not violate its principles if you write it according to REST principles. Yes it will violate its principles if you do not follow REST principles. Your code on the client and server side will have to obey REST rules. For example, if I send a "GET" to "...employee/22", it better send me a REST response e.g. 200, headers and content type etc. And doing all that will be basically doing what HTTP does.

---

Long Answer

The answer to your question is provided by @ГеоргиКременлиев. I actually think that might be the only correct answer.

It is true that REST is mostly tied to HTTP and when people speak about REST they're talking about HTTP. But, "mostly" does not mean "always" and even if it was "always" it still does not mean that REST is not possible without HTTP and that is pointed out in the links from @ГеоргиКременлиев answer. HTTP worked so well (Client and Server), the principles were taken to create any client/server application with those principles so they can enjoy the same benefits as HTTP. In other words,

1. Any client can be designed to understand REST (For example, browsers understand REST)
2. Any server can be designed to understand REST (For example, web servers understand REST)

Here is an important bit, REST principles were borrowed from HTTP. Therefore, if you are RESTful, it means you are following HTTP principles.

Having said that, if you do not want to use HTTP, then your client and/or server both have to understand the same language that HTTP speaks. For example, it uses verbs such as GET, POST, PUT etc. and response codes such as 200, 300, 400, and so on. Therefore, your server needs to understand how to respond to a request such as ...employee/22 and return:

• 200 OK, 301 moved permanently, 500 etc...
• Content-Type
• other headers needed

Your client also needs to understand those headers to be able to send requests to the server and consume responses from the servers.

And if you do implement all this, and security (authentication and authorization etc.), and chaching and the list goes on, you will realize you are just trying to re-invent the wheel: HTTP.

Is that worth it? Are you sure the bottleneck regarding performance was the HTTP protocol or was it your backend code, the queries to the database etc?

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.

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.

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.