기존 REST API 대신 SignalR (웹 소켓)을 사용하지 않는 유일한 이유는 성능입니까?

내가 사용했던 SignalR내 프로젝트의 여러 실시간 메시징 기능을 달성하기 위해. 안정적으로 작동하는 것 같고 사용법을 익히기가 매우 쉽습니다.

적어도 나에게 유혹은 웹 API 서비스 개발을 포기하고 SignalR모든 것에 사용 하는 것입니다.

나는 이것이 신중한 디자인으로 달성 될 수 있다고 생각하며, 그렇다면 클라이언트 코드가 훨씬 적게 필요하다는 것을 의미합니다. 더 중요한 것은 분할 인터페이스가 아닌 서비스에 대한 단일 인터페이스가 있으며 최악의 경우 사물이 렌더링되는 시점 에 대해 생각하지 않고이를 연결할 수 있다는 것입니다.

그래서 알고 싶습니다.

1. 성능 외에 모든 웹 서비스 대신 SignalR을 사용하지 않는 다른 이유가 있습니까?
2. SignalR의 성능이 적절하지 않을 정도로 충분히 관련되어 있습니까?

서버 측 객체 및 서비스 정의를 어리석은 것없이 클라이언트 측 서비스 액세스 코드로 변환 할 수 있다는 것은 오랫동안 꿈이었다 node.js. 내가 흥미있는 객체 정의 할 경우 예를 들어, InterestingObject과에 대한 서비스 CRUD객체를 InterestingObjectService, 내가 서비스에 대한 표준 URL 경로를 정의 할 수 있습니다 - 말을, "/ {서비스 명} / {methodName로}"-하지만, 난 여전히 액세스 쓰기 클라이언트 코드에 필요 서비스. 객체가 서버와 다시 클라이언트에서 전달 될 것입니다 때문에, 할 실질적인 이유가 없다 가지고는클라이언트 측 코드에서 객체를 명시 적으로 정의하거나 CRUD 작업을 수행하기위한 경로를 명시 적으로 정의 할 필요가 없습니다. 서비스 액세스가 클라이언트에서 서버로 작동하고 WinForms 또는 Java를 작성하는 것처럼 투명하게 다시 작동한다는 가정하에 클라이언트를 작성할 수 있도록이 모든 것을 표준화하는 방법이 있어야한다고 생각합니다. 애플릿 또는 기본 앱 또는 무엇을 가지고 있습니까?

SignalR이 전통적인 웹 서비스 대신 사용하기에 충분할 경우이를 달성하기위한 실용적인 방법 일 수 있습니다. SignalR에는 허브가 내가 설명하는 서비스처럼 작동하도록하는 기능이 이미 포함되어 있으므로이 모든 기능을 기본적으로 제공하는 CRUD (Common Base) 서비스를 정의 할 수 있습니다. 그런 다음 서비스 액세스 권한을 거의 얻었으므로 컨벤션으로 액세스 할 수있는 코드에 다시 코드를 작성하는 번거 로움을 덜어주었습니다. 더 중요한 것은 코드를 작성하는 데 소요되는 시간을 업데이트하는 방법을 정의하는 것입니다 DOM.

내 편집 내용을 읽은 후에는 약간 무의미한 것처럼 느껴지므로 내가받는 것에 대해 궁금한 점이 있으면 언제든지 문의하십시오. 기본적으로 서비스 액세스를 최대한 투명하게 만들고 싶습니다.

이 두 기술의 목적은 매우 다릅니다.

• REST는 API의 일반적인 호출을위한 것이며 클라이언트 는 교환 의 활성 행위자 입니다. 클라이언트가 주소의 GPS 좌표를 찾아야하는 경우 클라이언트 는 API 호출을 시작하고 좌표를 받거나 오류가 발생하거나 시간 초과가 경과 할 때까지 기다립니다.

• 웹 소켓은 반대 방향으로 일을해야하는 모든 것을위한 것입니다. 예를 들어, 실시간으로 로그와 다른 서버의 성능을 보여주는 인트라넷 웹 사이트를 사용 하면 클라이언트가 수동적 일 수 있으며 서버가 새로 게시 된 로그 메시지 나 성능 메트릭을 보낼 때까지 기다릴 수 있습니다 .

차이점은 분명합니다. 첫 번째 경우, 클라이언트는 특정 정보가 필요한 시점을 결정합니다. 두 번째 경우, 클라이언트는 단순히 연락을 기다리기만하면 언제 될지 알 수 없습니다.

어떤 식 으로든, 둘 다 상호 교환 가능합니다. 필요하지 않은 경우 웹 소켓을 구현할 수 있으며 (즉, 클라이언트가 REST 호출 대신 웹 소켓을 통해 서버를 호출 함) 폴링 또는 롱 폴링을 웹 소켓 (웹 소켓이 널리 보급 될 때까지 수년간 성공적으로 사용됨).

그러나 그들의 호환성은 비용이 듭니다.

• 웹 소켓 대신 폴링 또는 롱 폴링을 사용하면 종종 대역폭을 낭비하게됩니다.

• 웹 소켓을 사용하여 웹 API를 통해 수행 할 수있는 작업을 수행 할 때는 모든 활성 클라이언트의 모든 연결을 열어 두어야합니다. 실제로 원하는 것이 아닐 수도 있습니다. 동시에 최대 5 명의 클라이언트를 보유 할 것으로 예상되는 소규모 웹 사이트의 경우 이는 문제가되지 않습니다. Amazon AWS와 같은 서비스의 경우 기술적으로 쉽게 해결할 수 없습니다.

필요하지 않을 때는 웹 소켓을 사용하지 마십시오. 주소의 GPS 좌표를 얻으려면 웹 소켓 연결 열기, 전화 걸기, 응답 대기 및 연결 닫기에서 아무것도 얻지 못합니다. REST는 이러한 시나리오에 대한 요구를 충족시킵니다.

• 서비스에 대한 REST 호출을 통해 정보를 반복적으로 자주 확인하는 경우 웹 소켓으로 이동해야한다는 좋은 신호일 수 있습니다. 마찬가지로, 스택 오버플로는 웹 소켓을 사용하여 대역폭 사용량을 줄입니다. 이는 사람들이 새 메시지가 있는지 확인하기 위해 홈 페이지에서 F5를 누르는 데 시간을 소비하지 않기 때문입니다.

• 웹 소켓 연결을 열면이를 사용하여 단일 호출을 한 후 닫거나 연결이 열린 채로 있지만 서버가 클라이언트의 요청으로 만 클라이언트에게 무언가를 보내는 경우 REST로 전환하십시오.

또한 웹 소켓은 여전히 제한적으로 지원 되며 항상 구현하기 쉽지는 않습니다. SignalR을 사용하면 쉽게 구현할 수 있지만 다른 언어 / 컨텍스트 / 환경에서 구현하는 데 어려움이 없음을 의미하지는 않습니다. REST를 사용하면 쉽습니다. curl모든 주류 언어에서 사용할 수있는 통화 또는 유사한 기능 일 수 있습니다. 웹 소켓을 사용하면 [아직 모르는 언어의 이름을 입력하십시오]를 사용하여 클라이언트를 만드는 데 시간이 얼마나 걸리는지 확신 할 수 없습니다.

.NET, Python 및 node.js의 여러 프로젝트에서 웹 소켓을 사용했습니다.

• .NET에서는 그렇게 어렵지 않았지만 여전히 며칠 동안 연결이 열리자 마자 연결이 끊어지는 것과 같은 몇 가지 암호 문제를 알아 내려고 노력했습니다. (이것은 SignalR 이전이었습니다. 나는 결코 SignalR을 시도하지 않았습니다). 또한 웹 소켓 모드에서 WCF를 사용했는데 문제가 없었습니다 (그러나 WCF에는 항상 문제가 있다고 생각합니다 ).

• node.js에서는 이것이 가능했지만 작동하는 라이브러리를 찾을 때까지 라이브러리를 두 번 전환해야했습니다. 웹 소켓 Hello World를 만드는 데 일주일 이상을 보냈다고 생각합니다.

• 파이썬에서는 한 번 시도하고 2-3 일을 보냈으며 포기했습니다. 결코 효과가 없었습니다.

이것을 REST와 비교하십시오 : 새로운 언어 / 프레임 워크에서 발생할 수있는 유일한 문제는 파일을 POST하거나 매우 큰 이진 응답을받는 방법을 아는 것입니다. 일부 언어에 대한 솔루션을 검색하는 데 몇 시간을 소비 한 것을 기억합니다. 그러나 특별한 경우에 몇 시간은 단순한 Hello World의 경우 며칠 또는 몇 주와 비교할 수 없습니다.

내 2 센트 만 ...

나는 그것이 실제로 성능에 관한 것이 아니라고 생각합니다. 표준에 관한 것입니다. REST는 표준이며 IMHO는 다음과 같은 장점이 있습니다.

• HTTP 요청은 사용하기 쉽습니다. 누구나 REST API를 빠르게 사용할 수 있습니다. 도대체 브라우저를 열고 URL을 입력하여 데이터를 볼 수 있습니다.
• (거의) 모든 프로그래밍 언어에서 사용할 수 있습니다. 일종의 범용 인터페이스입니다. 이국적인 언어에서 SignalR과의 인터페이스는 덜 분명해 보입니다.
• http://petstore.swagger.wordnik.com/ 과 같은 훌륭한 툴링 지원이 있습니다 .
• 디버깅하기에 좋은 "인터페이스"입니다. 브라우저에서 직접 들어오고 나가는 메시지를 쉽게 모니터링하고 데이터 등을 볼 수 있습니다.