동일한 응용 프로그램에서 RESTful HTTP 및 웹 소켓?

애플리케이션이 이미 WebSocket라이브 피드를 위해 열린 AJAX경우 서버와의 다른 통신에 이를 사용해야 합니까?

연결이 이미 열려 있기 때문에 Request/Response실시간 이 아닌 요청에 사용해야 합니까?

RESTful HTTP요청을 더 쉽게 디버깅 할 수 있기 때문에 요청을 선호 합니다. URL 또는 컬이있는 브라우저를 사용하여 API가 반환하는 내용을 테스트 할 수 있습니다. 를 열기 위해 코드를 작성할 필요는 없습니다 WebSocket.

가지고 이상한 것 RESTful HTTP API과 WebSocket같은 응용 프로그램에서?

rest ajax websockets

— 마크
소스

"API를 테스트하기 위해 코드를 작성할 필요가 없습니다"이것을 좀 더 설명해 주시겠습니까? API를 테스트 할 필요가 없다고 생각하는 이유는 무엇입니까?

— Elias Van Ootegem

내가 잘못 아니에요 경우 크롬 개발자 도구를 사용하면 웹 소켓을 열고 메시지를 실시간으로 보낼 수

— maple_shaft

@EliasVanOotegem 좋은 지적입니다. 명확하지 않은 죄송합니다. 여전히 서버 측에서 단위 프로젝트로 API를 테스트해야합니다. 내 말은, API가 무엇을 반환하는지 간단히 살펴보고 싶다면 URL과 함께 broswer를 사용할 수 있습니다. 웹 소켓을 열기 위해 코드를 작성할 필요가 없습니다. 내 질문을 업데이트했습니다.

— Marc

@maple_shaft 훌륭하지만 서버에 WebSocket이 열린 페이지에 있어야합니다.

— Marc

Websocket의 핵심 설계 목표 중 하나는 HTTP 및 Websocket 프로토콜이 동일한 포트를 통해 통신 될 수 있다는 것입니다. 이를 위해서는 클라이언트가 HTTP 업그레이드 요청으로 Websocket 핸드 셰이크를 명시 적으로 수행해야합니다. 이러한 방식으로 서버는 표준 HTTP 요청 연결과 HTTP 양방향 요청을 이제 영구 양방향 이중 연결로 업그레이드 할 수 있습니다.

따라서 그렇습니다. 이것은 분명히 유효한 유스 케이스입니다. 그러나 특정 응용 프로그램에 대해 수행 해야하는지 여부는 완전히 다른 문제입니다. 웹 소켓은 서버가 요청하지 않은 데이터를 클라이언트 (실시간 피드)로 전송할 수 있어야하는 시나리오가있는 경우 유용하고 의미가 있습니다. HTTP 프로토콜 및 REST 서비스는 데이터의 동기 클라이언트 요청을 차단하려는 경우에 유용합니다.

요구 사항이 두 가지 모두 응용 프로그램에 적합하다면 반드시 두 가지를 모두 사용해야합니다. 그러나 서버와의 유일한 상호 작용이 라이브 피드 기반 인 경우 REST 서비스가 적합하지 않습니다. 디자인을 설계해야하는 시스템 품질 특성 측면에서 디버깅 용이성이 중요도가 낮은 것으로 생각 합니다.

— maple_shaft
소스

그것이 내가 궁금했던 것입니다. 실시간 라이브 피드에 웹 소켓을 사용하는 것이 합리적이지만 CRUD 작업은 어떻습니까? 표준 HTTP 요청을 사용하는 것이 더 의미가 있습니다.

— Marc

@Marc, CRUD 작업과 실시간 관심사 (HTTP를 다른 웹 소켓을 사용하는 것)를 분리하는 것이 이상하지는 않지만 서버에서 더 나은 응답 성을 얻을 것이라고 생각합니다. 모든 작업에 지속적인 연결 (Websocket)을 사용하면 성능이 향상됩니다. 이것은 실제로 CRUD 요구 사항에 달려 있지만 CRUD 웹 소켓 인터페이스에서 멀어지지 않습니다.

— Myst

공감! 여기 초보자는 둘 다 동일한 포트를 통해 통신해야한다고 언급했기 때문에 라이브 스트림에서 주식 가격을 가져오고 트래픽이 많기 때문에 스트림이 몇 분 동안 연결이 끊어지면 어떻게 데이터를 가져올 수 있습니까? 이 사건을 해결하기위한 전략이 존재합니다

— PirateApp