About socket programming and REST design

Question

We need to design a server that will serve a webpage to several clients but also query a remote database for these clients. One of the requirement for this project is that the whole system must be compliant with the REST architecture style. We need use Java as programming language but many questions arised while we were designing it.

We want to have a main thread that will get connections, as shown in this example:

// System.out.println("Starting a new web server using port " + port)

    try {
        ServerSocket reciever = new ServerSocket(port);
        while (true) {
            try {
                Socket s = reciever.accept();
                Client c = new Client(s);       
            } catch (IOException e) {
                System.err.println("New item creation failed.");
                IOUtil.close(reciever);
            } catch (InterruptedException e) {
                e.printStackTrace();
            }
        }
    } catch (IOException e) {
        System.err.println("ServerSocket problem.");
    }

Then each connection will be created as a new thread (the Client object in the code) that will take care of reading ONE request. If the request is a GET, then the thread will serve the resource to the client. If it is a POST, then it will add the request to a buffer and let another thread handle the query to the database and also the answer back to the client. After handling this only request, the thread closes the socket and terminates.

Is the use of sockets violating the REST principle? In order to respect the REST architecture, do we need to destroy every Client object (thread & socket) after each HTTP message? Is there another way of client-server communication that does not use sockets?

Why on earth are you not using JEE? The entire server thing is taken care of for you, all you have to do is decide what path a function should listen to and write some logic behind it (if you choose to use servlets). Seriously, you should not waste a second more reinventing the wheel. — thecoshman, Dec 16 '13 at 12:53
Ok so we looked at the Apache HHTPComponents, it seems like a good API for our task. It this what you are talking about? — tyrana4, Dec 16 '13 at 13:14
What? AFAIK Apache has nothing to do with JEE. You would run a 'container', something like JBoss. This container would manage all the boring web stuff. You can then just write one class (for starters), annotate a function with something like `@Path('/mySite/cakes/')` and that function will be called for any URL that matches that. — thecoshman, Dec 17 '13 at 09:21
Ah ok, sorry about this. I thought that Apache Tomcat was also a kind of servlet container.Thanks for your advice but this does not really answer the question though. — tyrana4, Dec 18 '13 at 00:14

score 2 · Accepted Answer · answered Dec 21 '13 at 22:47

Ok, I think you are confusing a whole bag of junk together.

Firstly, different between low level IP sockets that allow data to go from A to B and 'websockets' that use HTTP to bootstrap a connection from a client to a server that can be kept open for TWO WAY communication.

Based on your requirements, you just want a 'standard' JEE container. Using something like JAX-RS you can apply some basic annotations to functions such as @PATH('/MyResource/Cars/') and have that function be called for that path.

Using a container will free you from all that boring boilerplate rubbish. No need to manual setup threads to listen, and spawn other threads to handle requests.

Using IP sockets is (indirectly) a mandate of REST; REST has to (according to Fielding, but strictly speaking it is protocol agnostic) be over HTTP, thus over TCP/IP sockets (though obviously you could do HTTP over any other transport protocol). Websockets however are using HTTP to form a persistent stateful connection between client and server, which is fundamentally opposed to REST. Basic HTTP would (and you would do this via the container doing it for you) fully open and close the connection for each isolated request, in practice however HTTP (and thus REST) will allow for the low level connection (the TCP connection that is slow to start) to be maintained for a series of request. This functionality is intended for the scope of loading a HTML page, and all resources in one TCP connection, but over many HTTP requests.

score 1 · Answer 2 · answered Dec 15 '13 at 12:39

1

Sockets move bytes over TCP/IP. That's a lower level protocol, you don't want to worry about that. You care about the higher up protocol (which in this case is HTTP).

Sockets are closed in HTTP after every request, so what you're thinking sounds reasonable. Although I'm not sure why you would create a separate thread for a POST request. I'm assuming that your Client implementation already runs in its own thread (if it doesn't, then your server isn't very efficient).

answered Dec 15 '13 at 12:39

Kayaman

72,141
5
83
121

Actually, sockets don't _have_ to be closed after every request in HTTP/1.1 due to things like keep-alive. – Donal Fellows Dec 15 '13 at 16:53
@DonalFellows True, but I wanted to avoid delving too much into the intricacies. A simple HTTP server implementation would close the connection between requests, and the OP seems to be somewhat lacking on how different protocols work. – Kayaman Dec 15 '13 at 16:58

About socket programming and REST design

2 Answers2