О программировании сокетов и дизайне REST

Question

Нам нужно создать сервер, который будет обслуживать веб-страницу нескольким клиентам, а также запросить удаленную базу данных для этих клиентов. Одним из требований этого проекта является то, что вся система должна соответствовать стилю архитектуры REST. Нам нужно использовать Java в качестве языка программирования, но при разработке мы создали много вопросов.

Мы хотим, чтобы основной поток, который получит соединения, как показано в следующем примере:

// 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."); 
    } 

Затем каждое соединение будет создано как новый поток (объект клиента в коде), который будет принимать уход за чтением ОДНОГО запроса. Если запрос является GET, поток будет обслуживать ресурс для клиента. Если это POST, то он добавит запрос в буфер, а другой поток обработает запрос в базе данных, а также ответ обратно клиенту. После обработки этого единственного запроса поток закрывает сокет и завершается.

Является ли использование гнезд нарушением принципа REST? Чтобы уважать архитектуру REST, нужно ли уничтожать каждый объект Client (нить & сокет) после каждого HTTP-сообщения? Есть ли другой способ взаимодействия клиент-сервер, который не использует сокеты?

Answer 1

Хорошо, я думаю, вы сбиваете с толку целый мешок мусора.

Во-первых, разные между IP-разъемами низкого уровня, которые позволяют передавать данные от A до B и «веб-разъемы», которые используют HTTP, для загрузки соединения с клиента на сервер, который может быть открыт для двухсторонней связи.

Основываясь на ваших требованиях, вам просто нужен «стандартный» контейнер JEE. Используя что-то вроде JAX-RS, вы можете применить некоторые основные аннотации к таким функциям, как @PATH('/MyResource/Cars/') и вызвать эту функцию для этого пути.

Использование контейнера освободит вас от всего этого расточительного отброса. Нет необходимости в ручных настройках для прослушивания, а также создавать другие потоки для обработки запросов.

Использование IP-разъемов (косвенно) - мандат REST; REST должен (согласно Филдингу, но, строго говоря, агностик протокола) быть через HTTP, таким образом, через сокеты TCP/IP (хотя, очевидно, вы могли бы выполнить HTTP по любому другому транспортному протоколу). Однако Websockets используют HTTP для формирования постоянного соединения stateful между клиентом и сервером, что в корне противоречит REST. Основной HTTP (и вы сделаете это через контейнер, делающий это для вас) полностью откроете и закроете соединение для каждого изолированного запроса, однако на практике HTTP (и, следовательно, REST) ​​позволит подключиться к низкоуровневому соединению (TCP-соединение, которое медленное начало) для поддержки серии запросов. Эта функциональность предназначена для области загрузки HTML-страницы и всех ресурсов в одном TCP-соединении, но во многих HTTP-запросах.

Answer 2

Сокеты перемещают байты по протоколу TCP/IP. Это протокол более низкого уровня, вы не хотите беспокоиться об этом. Вы заботитесь о более высоком протоколе (который в данном случае является HTTP).

Сокеты закрываются по протоколу HTTP после каждого запроса, поэтому то, что вы думаете, звучит разумно. Хотя я не уверен, почему вы создадите отдельный поток для запроса POST. Я предполагаю, что ваша реализация Client уже работает в своем потоке (если нет, то ваш сервер не очень эффективен).