Работа с сокетами подразумевает наличие открытого порта на сервере и клиенте, что может быть не совсем удобно, если порт занят или если у клиента закрыто обращение к некоторым портам. Поэтому лучшим решением для взаимодействия между клиентом и сервером может стать работа по API сервера, используя HTTP. Таким API является REST.
REST( Representational state transfer) – архитектурный стиль взаимодействия компонентов распределённого приложения в сети. REST представляет собой согласованный набор ограничений, учитываемых при проектировании распределённой гипермедиа-системы. В нашем случае это приводит к повышению производительности и упрощению архитектуры. Компоненты в REST взаимодействуют наподобие взаимодействия клиентов и серверов во Всемирной паутине. В сети Интернет вызов удалённой процедуры может представлять собой обычный HTTP-запрос( обычно GET или POST; такой запрос называют RESTзапрос), а необходимые данные передаются в качестве параметров запроса. Серверы не связаны с интерфейсами клиентов и их состояниями. Клиент отсылает запросы, когда готов совершить транзакцию на изменение состояния. Каждый из клиентов, а также промежуточные узлы между сервером и клиентами могут кэшировать ответы сервера. Правильное использование кэширования в REST-архитектуре устраняет избыточные клиент-серверные взаимодействия, что улучшает скорость и расширяемость системы [ 9 ].
Рис. 3. Пример программы клиента
Рис. 4. Логическая структура работы между сокетом и клиентом
Пример такой работы описан в следующем рисунке( Рис. 5). В нем часть кода приложения, отвечающего за GET запросы, позволяет показывать необходимую нам информацию.
Рис. 5. Класс, отвечающий на GET запросы
В результате первый метод при переходе в браузере по адресу http:// localhost / developers / покажет нам страницу с надписью“ duchess, duke”. Второй метод используется, когда нужно передать параметры http:// localhost / developer / first-last. В результате этого запроса сервер покажет нам введенные параметры
27