지속적인 연결이 필요한 프로토콜을위한 RESTful HTTP 게이트웨이를 설계하는 방법은 무엇입니까?

Question

저는 지속적인 클라이언트/서버 프로토콜로 작업하고 있으며 RESTful 게이트웨이를 설계해야합니다. 나는 REST 인터페이스를 설계하는 데 많은 경험이 없으며 서버에서 지속적인 연결을 유지하는 데 필요한 세션 ID와 자원으로 서버 상태를 나타내는 방법을 (RESTful 방식으로) 어떻게 처리해야하는지 이해하지 못한다.

"RESTful"으로 보이는 RPC-ish 결과로 끝내고 싶지 않기 때문에이 질문을하고 있습니다.

특정 문맥 문제 : 일시적인 노드와 시계를 지원하기 위해 기존 ZooKeeper REST 게이트웨이를 개선하고 싶습니다. 임시 노드는 클라이언트가 서버에 연결되어있는 동안 존재합니다.

감사합니다.

Answer 1

과거에 내가 해낸 방법은 '티켓'또는 '영수증'패턴을 따릅니다. REST 서비스는 자원 (보고서 이름, z 노드 등)에 대한 요청을 승인하고 티켓을 리턴합니다. 이 티켓 (일반적으로 UUID 또는 유사 함)을 사용하여 세션을 나타낼 수 있습니다. 후속 요청은이 티켓을 사용하여 요청 상태를 확인합니다. 티켓의 만료를 보장하기 위해 두 가지 경우 중 하나가 발생합니다. 티켓을 시간 초과하거나 결과를 받으면 클라이언트는 서비스에 ACK (승인)를 제공해야합니다.

ex.

요청 : GET/사육사/znode/임시/foo는 응답 : 1234-1234-1234-1234

요청 : GET/사육사/상태/1234-1234-1234-1234 응답 : WORKING (또는)를 사용할 수 없거나 차단되거나 NOTREADY 또는 ... 실패

요청 : GET/사육사/상태/1234-1234-1234-1234 응답 : 후천성 (AVAILABLE 또는 확인 또는 SUCCESS 또는 일부 값 (s 또는) ...)

요청 : GET/zookeeper/acknowledge/1234-1234-1234-1234 응답 : OK (또는 UNKNOWN 티켓 등)

재미있는 관리 메시지 :

요청 : GET/사육사/세션 (또는/티켓) 응답 : [1234, 5668, ...]

요청 : GET/zookeeper/kill/ 응답 : OK (또는 UNKNOWN 또는 FAILED ...)

이것은 매우 잘 작동했습니다. 이것은 REST 서비스가로드 밸런싱과 같은 것들을보다 교묘하게 만드는 상태 유지라는 것을 의미합니다. 필자는 서버 ID가 각 응답과 함께 반환되도록하는 프로토콜을 사용했으며 클라이언트가 다른 서버 ID와 알 수없는 티켓을 받으면 대화하고 있던 서비스가 죽었다가 다시 시작한다고 가정합니다. 이는 끈적한로드 밸런싱을 의미합니다 (즉, 라운드 로빈은 여기서 작동하지 않습니다). REST 서비스는 이러한 요청을 병렬로 처리하고 티켓 데이터베이스 (대개 메모리, 동기화 된 해시 테이블 구조) 및 세션/티켓 시간 초과 스레드에 대한 액세스를 제공하기 위해 멀티 스레드되어야합니다.

희망이 도움이됩니다.