웹 소켓을 통한 ReST가 가능합니까?

웹 소켓을 통한 ReST가 가능합니까?

---

ReSTful 요청을 받아 XMPP로 변환하여 XMPP 서버로 전달하는 웹 기반 채팅 애플리케이션을 개발할 계획입니다.

이러한 종류의 채팅 기반 애플리케이션에 웹 소켓을 사용하는 것은 이벤트 (또는 응답)가 비동기 적으로 전달 될 수 있기 때문에 유망 해 보였습니다. 그러나 브라우저에서 요청을 전송하기위한 기본 프로토콜로 웹 소켓을 사용하는 경우에도 여전히 ReSTful 설계로 간주 될 수 있습니까? 그렇다면 웹 소켓 메시지에 URI, 동사 (GET, POST ...), 매개 변수가 어떻게 표시됩니까? xml / json으로 감싸서 보내시겠습니까?

또한 ReSTful 아키텍처는 세션 상태가 서버에 저장되지 않는다고 말합니다. 그러나이 경우 XMPP 클라이언트 세션이 생성되면이 세션의 상태가 서버에 저장됩니다 (상태 비 저장 제약 조건 위반).

---

REST는 프로토콜을 부과하지 않는 아키텍처 스타일입니다. 예, 원하는 경우 웹 소켓으로 REST, HTTP로 REST, FTP로 REST를 수행 할 수 있습니다.

HTTP를 사용하는 주된 이유는 HTTP를 통해 모든 구성 요소 또는 프로그래밍 언어와 통신하는 것이 쉽고 매우 간단하기 때문이며 또한 HTTP는 프록시, 방화벽 등 여러 중개자가있는 분산 환경을 지원하기 때문입니다. 따라서 모든 토폴로지에 서비스를 배포 할 수 있으며 누구나 액세스 할 수 있습니다.

내 말 : 당신이 RESTliban이고 Roy Fielding의 논문이 진실의 근원이라면 동사는 결코 의미론의 일부로 인정되지 않습니다. URI는 의미 체계입니다. 서로 다른 동작에 대해 서로 다른 동사를 사용하는 것은 HTTP를 통한 REST의 우아한 발전 이었지만 "진실"의 일부는 아닙니다. Roy 가 그의 논문 6 장에서 평가 한 HTTP를 통한 휴식 시나리오를 확인할 수 있습니다 . 동사에 대한 언급이 없습니다. 그리고 이것은 사양이 아니라 평가 시나리오라는 점에 유의하십시오.

TLDR;

인터넷을 통한 실시간 양방향 통신이 필요하고 클라이언트가 웹 브라우저 인 경우 가장 좋은 선택은 웹 소켓입니다. 그런 다음 웹 소켓 위에 애플리케이션 수준 프로토콜을 구현하여 RESTful 웹 서비스를 구현할 수 있습니다.

---

예. SwaggerSocket 과 같은 라이브러리와 함께 WebSocket을 통해 REST를 사용할 수 있습니다 .

---

소켓 위에 REST API를 빌드하려는 이유는 무엇입니까? IMHO REST API의 이점은 상태 비 저장 요청과 같은 표준 HTTP 프로토콜 가능성, GET, DELETE와 같은 의미 동사를 활용하여 (클라이언트) 개발자가 쉽게 이해할 수있는 API를 구축하는 것입니다. 소켓은 HTTP 동사 등을 제공하지 않기 때문에 IMHO가 합리적이지 않은 소켓에 대해 일종의 HTTP 계층을 구축합니다.

정말로 그런 것을 구축하려는 경우에는 HTTP 프로토콜을 청사진으로 사용하고 HTTP와 같은 소켓 프로토콜을 구현하는 것이 좋습니다.

---

XMPP를 REST로 변환 한 다음 WS를 통해 REST를 실행하는 이유를 이해할 수 없습니다. WebSocket의 요점은 XMPP 프로토콜을 브라우저로 직접 가져와 모든 번역 문제를 피하는 것입니다.

브라우저에서 서버로 XMPP를 통신 할 수있는 JavaScript 라이브러리가 있습니다. 필요한 것은 WS에서 TCP로 XMPP 트래픽을 프록시 한 다음 XMPP 서버로 직접 프록시하는 것입니다. Kaazing에는 이를 수행 할 수 있는 게이트웨이 가 있습니다.

오픈 소스를 사용하려면 JavaScript XMPP 라이브러리를 작성해야합니다. 간단한 프로토콜을위한 JS 라이브러리를 작성하는 방법을 보여주는 예제가 있습니다. 하나를 찾아서 개념을 XMPP 프로토콜로 확장하기 만하면됩니다.

요약하자면 다음은 아키텍처의 모습입니다.

XMPP 클라이언트 코드 <-> XMPP JavaScript 라이브러리 <-> WebSocket over http <-> WebSocket to TCP Proxy <-> XMPP Server

여기서 XMPP 클라이언트 코드와 XMPP JavaScript 라이브러리는 브라우저에서 실행되고 WS-TCP 프록시는 XMPP 서버와 함께 모두 서버 측입니다.

---

REST 아키텍처 스타일은 대부분 2 개의 엔티티 즉, 클라이언트와 서버.

실시간 웹과 반응 시스템의 개발로 더 나아가면 WebSocket은 REST API의 사용을 대체하기 시작했습니다.

WS는 서버와 클라이언트의 개념을 무시하는 데이터 푸시 및 풀을 허용합니다.

STOMP, AMQP, XMPP는 메시징 프로토콜로 사용할 수 있습니다.

데이터 자체는 JSON 또는 Google 프로토콜 버퍼 또는 Apache Avro 일 수 있습니다.

WebSockets는 웹 서버에 연결되어 있지 않지만 모바일 앱이나 데스크톱 앱과 같은 독립형 앱에서도 개발할 수 있습니다.

---

클라우드 솔루션과 게임용 "SaaS (Server-end / Service as a Platform)"를 제공하는 한 회사의 블로그에서 새로운 주제를 발견했습니다.

나는이 회사를 광고하지도 않고 사용하지도 않기 때문에 그들이 얼마나 좋은지 나쁜지조차 모릅니다.

그러나 REST에서 WebSocket을 사용하는 이유와 이점을 매우 명확하게 설명 합니다. 블로그를 읽어보십시오.

---

나는이 게시물이 정말 오래되었다는 것을 이해하지만 "내가 REST 아키텍처를 선택하면 실시간 통신 기능을 상실하게 되는가?"라는 개념에 대해 좀 더 삽입하고 싶었습니다.

한마디로, 아닙니다. 내가 경험 한 많은 REST 스타일 구현은 호환성, 검색 가능성을 위해 REST를 활용하고 IoT의 그림자에서 여러 장치에 걸쳐 확장 할 수있는 수단으로 사용했습니다.

그러나 REST 외에도 WS를 사용하여 거의 실시간 전송을 용이하게합니다. 또한이 작업에 실제로 도움이되고 API를 빌드하고 소비하는 애플리케이션의 RT 구성 요소가 작동해야하는 방식을 결정하는 데 집중할 수 있도록하는 추상화가 많이 있습니다.

REST API를 빌드하고 RT 요구에 맞게 휠을 다시 생성하지 않으려면 Tibco Smart-Sockets 또는 SignalR과 같은 것을 살펴 보는 것이 좋습니다.

---

웹 소켓 보내기 함수에 콜백을 추가하는 프로젝트를 만들었습니다. https://github.com/ModernEdgeSoftware/WebSocketR2

클라이언트가 콜백을 구현할 수 있도록 메시지 ID가 설정됩니다. 시간 초과 후 메시지 재 시도를 처리하고 연결이 끊어지면 서버에 다시 연결합니다. 그런 다음 동사와 경로를 추가하여 페이로드를 원하는만큼 RESTful로 구성 할 수 있습니다.

이것은 비디오 게임 스튜디오가 UDP를 사용하여 필요한 속도를 달성하는 것과 비슷하지만, 넷 코드는 안정성을 위해 TCP와 같은 많은 기능을 구현합니다.

참고URL : https://stackoverflow.com/questions/13373734/is-rest-over-websockets-possible