REST API를 대체하는 Websocket API?

웹 소켓 또는 긴 폴링을 통해 기본 기능이 실시간으로 작동하는 응용 프로그램이 있습니다.

그러나 대부분의 사이트는 RESTful 방식으로 작성되어 향후 애플리케이션 및 기타 클라이언트에 유용합니다. 그러나 REST에서 벗어난 모든 사이트 기능에 대해 웹 소켓 API로 전환하는 것을 생각하고 있습니다. 그러면 사이트의 모든 부분에 실시간 기능을 더 쉽게 통합 할 수 있습니다. 이것이 애플리케이션이나 모바일 클라이언트를 구축하는 것을 더 어렵게 만들까요?

나는 어떤 사람들이 이미 다음과 같은 일을하고 있음을 발견했다 : SocketStream

여기에있는 다른 답변에는 장점이 없다는 말이 아니라 좋은 점이 있습니다. 그러나 저는 일반적인 합의에 어긋나고 실시간 기능 이상을 위해 웹 소켓으로 이동하는 것이 매우 매력적이라는 데 동의합니다.

내 앱을 RESTful 아키텍처에서 웹 소켓을 통해 더 많은 RPC 스타일로 옮기는 것을 진지하게 고려하고 있습니다. 이것은 "장난감 앱"이 아니고 실시간 기능 만 말하는 것이 아니므로 예약을하고 있습니다. 그러나 나는이 길을 가면서 많은 이점을보고 그것이 탁월한 해결책이 될 수 있다고 생각합니다.

내 계획은 DNode , SocketIO 및 Backbone을 사용하는 것 입니다. 이러한 도구를 사용하면 단순히 RPC 스타일의 함수를 호출하여 클라이언트와 서버에서 내 백본 모델과 컬렉션을 전달할 수 있습니다. 더 이상 REST 끝점 관리, 개체 직렬화 / 역 직렬화 등을 수행 할 필요가 없습니다. 아직 socketstream으로 작업하지 않았지만 확인해 볼 가치가 있습니다.

이것이 좋은 솔루션이라고 확실히 말하기까지는 아직 갈 길이 멀고, 모든 애플리케이션에 가장 적합한 솔루션은 아니지만이 조합이 매우 강력 할 것이라고 확신합니다. 리소스 캐시 기능을 잃는 것과 같은 몇 가지 단점이 있음을 인정합니다. 그러나 나는 장점이 그들보다 클 것이라고 생각합니다.

이러한 유형의 솔루션을 탐색하는 진행 상황을 추적하고 싶습니다. github 실험이 있으시면 저에게 알려주세요. 아직은 없지만 곧있을 수 있기를 바랍니다.

아래는 내가 수집 한 나중에 읽을 링크 목록입니다. 나는 그것들 중 많은 것을 훑어 보았 기 때문에 그것들이 모두 가치가 있다는 것을 보증 할 수 없습니다. 그러나 일부는 도움이 될 것입니다.

Express와 함께 Socket.IO 사용에 대한 훌륭한 자습서. 그것은 socket.io에 익스프레스 세션을 노출하고 인증 된 각 사용자에 대해 다른 방을 갖는 방법에 대해 설명합니다.

• http://www.danielbaulig.de/socket-ioexpress/

인증, Joyent 호스팅 등을 사용하는 node.js / socket.io / backbone.js / express / connect / jade / redis에 대한 자습서 :

• http://fzysqr.com/2011/02/28/nodechat-js-using-node-js-backbone-js-socket-io-and-redis-to-make-a-real-time-chat-app/
• http://fzysqr.com/2011/03/27/nodechat-js-continued-authentication-profiles-ponies-and-a-meaner-socket-io/

Backbone.js와 함께 Pusher를 사용하는 방법에 대한 자습서 (Rails 사용) :

• http://blog.pusher.com/2011/6/21/backbone-js-now-realtime-with-pusher

클라이언트에서 backbone.js를 사용하고 서버에서 express, socket.io, dnode를 사용하여 node.js로 애플리케이션을 빌드하십시오.

• http://andyet.net/blog/2011/feb/15/re-using-backbonejs-models-on-the-server-with-node/
• http://addyosmani.com/blog/building-spas-jquerys-best-friends/
• http://fzysqr.com/2011/02/28/nodechat-js-using-node-js-backbone-js-socket-io-and-redis-to-make-a-real-time-chat-app/
• http://fzysqr.com/2011/03/27/nodechat-js-continued-authentication-profiles-ponies-and-a-meaner-socket-io/

DNode와 함께 백본 사용 :

• http://quickleft.com/blog/backbone-without-ajax-part-ii
• http://quickleft.com/blog/backbone-without-ajax-part-1
• http://sorensen.posterous.com/introducing-backbone-redis
• https://github.com/cowboyrushforth/minespotter
• http://amir.unoc.net/how-to-share-backbonejs-models-with-nodejs
• http://hackerne.ws/item?id=2222935
• http://substack.net/posts/24ab8c

HTTP REST와 WebSocket은 매우 다릅니다. HTTP는 상태 비 저장 이므로 웹 서버는 아무것도 알 필요가 없으며 웹 브라우저와 프록시에서 캐싱됩니다. WebSocket을 사용하는 경우 서버가 상태 저장 이되고 서버 의 클라이언트에 연결해야합니다.

요청-응답 통신과 푸시

WebSockets 는 서버에서 클라이언트로 데이터 를 PUSH 해야하는 경우에만 사용 합니다. 해당 통신 패턴은 HTTP에 포함되지 않습니다 (해결 방법에 의해서만). PUSH는 다른 클라이언트가 만든 이벤트를 다른 연결된 클라이언트에서 사용할 수 있어야하는 경우에 유용합니다 (예 : 사용자가 다른 클라이언트 동작에 따라 행동해야하는 게임). 또는 웹 사이트가 무언가를 모니터링하는 경우 서버가 항상 데이터를 클라이언트에 푸시합니다 (예 : 주식 시장 (라이브)).

서버에서 데이터를 PUSH 할 필요가없는 경우 일반적으로 상태 비 저장 HTTP REST 서버를 사용하는 것이 더 쉽습니다. HTTP는 간단한 요청-응답 통신 패턴을 사용합니다.

모든 사이트 기능에 대해 WebSocket API로 전환하는 것에 대해 생각하고 있습니다.

아뇨. 그렇게해서는 안됩니다. 두 모델을 모두 지원해도 아무런 문제가 없습니다. 단방향 통신 / 간단한 요청 에는 REST 를 사용하고 양방향 통신에는 WebSocket 을 사용하십시오. 특히 서버가 실시간 알림을 보내려고 할 때.

WebSocket 은 RESTful HTTP 보다 더 효율적인 프로토콜 이지만 여전히 아래 영역에서 WebSocket을 통한 RESTful HTTP 점수입니다.

1. HTTP에 대해 리소스 생성 / 업데이트 / 삭제가 잘 정의되었습니다. WebSocket에 대해 낮은 수준에서 이러한 작업을 구현해야합니다.

2. WebSocket 연결은 HTTP 연결이 수평으로 확장되는 단일 서버에서 수직으로 확장됩니다. WebSocket 수평 확장을위한 독점적 인 비표준 기반 솔루션이 있습니다.

3. HTTP는 캐싱, 라우팅, 멀티플렉싱, gzipping 등과 같은 많은 좋은 기능을 제공합니다. Websocket을 선택한 경우 Websocket 위에 빌드해야합니다.

4. 검색 엔진 최적화는 HTTP URL에서 잘 작동합니다.

5. 모든 프록시, DNS, 방화벽은 아직 WebSocket 트래픽을 완전히 인식하지 못합니다. 포트 80을 허용하지만 먼저 스누핑하여 트래픽을 제한 할 수 있습니다.

6. WebSocket을 사용한 보안은 전부 또는 전혀 접근하지 않습니다.

자세한 내용 은이 기사 를 참조하십시오.

TCP (WebSockets)를 주요 웹 콘텐츠 전달 전략으로 사용할 수있는 유일한 문제는 TCP를 사용하여 웹 사이트 아키텍처 및 인프라를 설계하는 방법에 대한 읽기 자료가 거의 없다는 것입니다.

따라서 다른 사람들의 실수로부터 배울 수 없으며 개발 속도가 느려질 것입니다. 또한 "시도되고 검증 된"전략이 아닙니다.

물론 HTTP의 모든 이점을 잃게 될 것입니다 (상태 비 저장이고 캐싱이 더 큰 이점입니다).

HTTP는 웹 콘텐츠를 제공하기 위해 설계된 TCP의 추상화입니다.

그리고 SEO와 검색 엔진은 웹 소켓을 수행하지 않는다는 것을 잊지 마십시오. 따라서 SEO를 잊을 수 있습니다.

개인적으로 나는 너무 많은 위험이 있기 때문에 이것을 권장하지 않습니다.

웹 사이트 서비스에 WS를 사용하지 말고 웹 애플리케이션 서비스에 사용하십시오.

그러나 장난감이나 개인 웹 사이트가 있다면 꼭 가십시오. 시도해보십시오. 최첨단이 되십시오. 비즈니스 또는 회사의 경우이 작업의 위험을 정당화 할 수 없습니다.

나는 약간의 교훈을 배웠다 (어려운 방법). Ubuntu AWS EC2 클라우드 서비스 (강력한 GPU 사용)에서 실행되는 수많은 처리 애플리케이션을 만들었고 진행 상황을 실시간으로 확인하기 위해 프런트 엔드를 만들고 싶었습니다.실시간 데이터가 필요했기 때문에 업데이트를 푸시하기 위해 웹 소켓이 필요하다는 것이 분명했습니다.

개념 증명으로 시작하여 훌륭하게 작동했습니다. 하지만 대중에게 공개하려면 사용자 세션을 추가해야했기 때문에 로그인 기능이 필요했습니다. 그리고 어떻게 보든 웹 소켓은 어떤 사용자를 처리하는지 알아야하므로 웹 소켓을 사용하여 사용자를 인증하는 지름길을 사용했습니다 . 당연해 보였고 편리했습니다.

우리는 실제로 연결을 안정적으로 만들기 위해 조용히 시간을 보내야했습니다. 저렴한 웹 소켓 튜토리얼로 시작했지만 연결이 끊어졌을 때 구현이 자동으로 다시 연결할 수 없음을 발견했습니다. socket-io로 전환했을 때 모든 것이 개선되었습니다.Socket-io는 필수입니다!

솔직히 말해서 몇 가지 훌륭한 socket-io 기능을 놓친 것 같습니다. Socket-io는 더 많은 것을 제공하고 있으며, 초기 디자인에서 고려한다면 더 많은 것을 얻을 수 있다고 확신합니다. 대조적으로, 우리는 이전 웹 소켓을 socket-io의 웹 소켓 기능으로 바꿨습니다. (방, 채널 없음, ...) 재 설계는 모든 것을 더 강력하게 만들 수 있습니다. 하지만 그럴 시간이 없었습니다. 다음 프로젝트에서 기억해야 할 사항입니다.

다음으로 점점 더 많은 데이터 (사용자 기록, 송장, 거래 등) 를 저장 하기 시작했습니다 . 우리는 모든 것을 AWS dynamodb 데이터베이스에 저장했고, 다시 socket-io를 사용하여 프런트 엔드에서 백엔드로 CRUD 작업을 전달했습니다. 나는 우리가 거기에서 잘못된 방향을 택했다고 생각합니다. 그건 실수 였어.

• Amazon의 클라우드 서비스 (AWS) 가 RESTful 애플리케이션을위한 훌륭한 로드 밸런싱 / 스케일링 도구를 제공한다는 사실을 알게 된 직후 입니다.
• 이제 우리 는 CRUD 작업 의 핸드 셰이크를 수행하기 위해 많은 코드를 작성해야한다는 인상을 받았습니다 .
• 최근에 우리는 Paypal 통합을 구현했습니다. 우리는 그것을 작동시킬 수있었습니다. 그러나 다시 모든 튜토리얼은 RESTful API를 사용하여 수행합니다 . 웹 소켓으로 구현하기 위해 예제를 다시 작성 / 다시 생각해야했습니다. 그래도 상당히 빠르게 작동합니다. 그러나 우리가 흐름에 반대하는 것처럼 느껴집니다 .

그 모든 것을 말했듯이, 우리는 다음 주에 라이브를 시작할 것입니다. 우리는 제 시간에 도착했고 모든 것이 작동합니다. 빠르지 만 확장 될까요?

나는 둘 다 사용 하는 것을 고려할 것 입니다. 각 기술마다 장점이 있으며 모든 솔루션에 적합한 단일 크기는 없습니다.

작업 분리는 다음과 같이 진행됩니다.

1. WebSocket 은 세션이 필요한 서버와 통신하는 애플리케이션 의 기본 방법 입니다. 이것은 이전 브라우저에 필요한 많은 해킹을 제거합니다 (문제는이를 제거 할 이전 브라우저에 대한 지원입니다).

2. RESTful API 는 브라우저 캐싱의 혜택을받는 세션 지향 (즉, 인증이 필요하지 않음) 이 아닌 GET 호출에 사용됩니다 . 이에 대한 좋은 예는 웹 애플리케이션에서 사용하는 드롭 다운에 대한 참조 데이터입니다. 하나. 보다 자주 변경 될 수 있습니다.

3. HTML 및 자바 스크립트. 이것들은 웹앱의 UI를 구성합니다. 이들은 일반적으로 CDN에 배치되는 것이 좋습니다.

4. WSDL을 사용하는 웹 서비스 는 메시지 및 데이터 전달에 대해 잘 정의 된 표준을 제공하므로 여전히 엔터프라이즈 수준 및 기업 간 통신에 가장 좋은 방법입니다 . 주로이를 Datapower 장치로 오프로드하여 웹 서비스 핸들러에 프록시합니다.

이 모든 것은 이미 SSL을 통해 보안 소켓을 사용하는 HTTP 프로토콜에서 발생합니다.

하지만 모바일 애플리케이션의 경우 웹 소켓은 연결이 끊긴 세션 ( 연결을 닫은 후 웹 소켓에 다시 연결하는 방법)에 다시 연결할 수 없으며 관리도 간단합니다. 따라서 모바일 앱의 경우 여전히 REST API 및 폴링을 권장 합니다.

WebSockets vs REST를 사용할 때주의해야 할 또 다른 사항은 확장 성 입니다. WebSocket 세션은 여전히 ​​서버에서 관리합니다. RESTful API는 적절하게 완료되면 상태 비 저장 (관리해야하는 서버 상태가 없음)이므로 확장 성이 수직보다 수평 (저렴)으로 증가 할 수 있습니다 .

서버에서 업데이트를 원합니까?

• 예 : Socket.io
• 쉬지 못한다

Socket.io의 단점은 다음과 같습니다.

• 확장 성 : WebSockets에는 개방형 연결과 웹 규모에 대해 훨씬 다른 Ops 설정이 필요합니다.
• 학습 : 학습 시간에 제한이 없습니다. 일을 완료해야합니다!

내 프로젝트에서는 여전히 Socket.io를 사용할 것이지만 REST가 잘하는 기본 웹 양식에는 사용하지 않습니다.

WebSocket (또는 긴 폴링) 기반 전송은 대부분 서버와 클라이언트 간의 (거의) 실시간 통신에 사용됩니다. 채팅이나 실시간 피드 또는 기타 항목과 같이 이러한 종류의 전송이 필요한 여러 시나리오가 있지만 일부 웹 애플리케이션의 모든 부분이 반드시 서버와 양방향으로 연결될 필요는 없습니다.

REST는 잘 이해되고 다른 아키텍처에 비해 고유 한 이점을 제공하는 리소스 기반 아키텍처입니다. WebSocket은 실시간으로 데이터를 스트리밍 / 피드하는 경향이 있으므로 리소스와 피드 (REST를 사용하지 않으려는 경우)의 우선 순위를 지정하거나 구분하기 위해 일종의 서버 기반 논리를 만들어야합니다.

나는 이 전송이 데이터 유형 / 양식 불가지론 적 전달의 형태로 더 널리 퍼지고 더 잘 이해 / 문서화 될 미래에 소켓 스트림 과 같은 더 많은 WebSockets 중심 프레임 워크가있을 것이라고 가정합니다 . 그러나 이것이 수많은 사용 사례와 시나리오에서 반드시 필요하지는 않은 기능을 제공하기 때문에 REST를 대체하거나 대체해야한다는 의미는 아닙니다.

이 질문에 대한 최선의 답변 인 이 블로그 게시물 을 지적하고 싶습니다 .

요컨대 예

이 게시물에는 이러한 종류의 API에 대한 모든 모범 사례가 포함되어 있습니다.

그건 좋은 생각이 아니다. 표준은 아직 확정되지 않았고, 브라우저에 따라 지원이 달라집니다. 지금이 작업을 수행하려면 플래시 또는 긴 폴링 등으로 대체해야합니다. 향후에도 여전히 서버가 모든 단일 사용자에게 연결을 열어 두는 것을 지원해야하기 때문입니다. 대부분의 웹 서버는 요청에 빠르게 응답하고 가능한 한 빨리 닫는 데 탁월하도록 설계되었습니다. 많은 수의 동시 연결을 처리하도록 운영 체제를 조정해야합니다 (각 연결은 더 많은 임시 포트와 메모리를 사용함). 가능한 한 많은 사이트에 REST를 사용하십시오.