턴제 게임 서버에 어떤 RESTful API를 사용하시겠습니까?
https://stackoverflow.com/questions/405588
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
Russian문제
턴제 게임 서버를 RESTful API로 어떻게 모델링하시겠습니까?예를 들어 동일한 API의 다른 클라이언트를 상대로 체스 게임을 할 수 있는 체스 서버가 있습니다.다른 클라이언트와 게임을 요청하고 협상하는 방법과 게임의 개별 동작을 플레이하는 방법이 필요합니다.
이것이 REST(RESTful) API에 적합한 후보입니까?아니면 다른 방식으로 모델링해야 합니까?
해결책
모델링하려는 리소스는 무엇입니까? 나는 당신, 당신의 상대, 특정 게임 (세션, 인스턴스) 및 게임 보드 상태를 4 개가있는 것 같습니다. 그래서 그것은 같은 것으로 시작합니다
/game
/game/gameID/gamer/gamerID
/game/gameID/board
우리는 좋은 소개/개요가 있습니다 정보 Q.
다른 팁
나는 다음과 같은 생각을 생각하고있다.
/game/<gameID>/move/<moveID>
기본 자원에 관한 한. "다른 플레이어가 아직 움직였습니까?" 그래도 아이디어. 이동이 재생 될 때까지 간단히 GET 요청 블록을 갖는 것에 대해 생각했습니다. 내 클라이언트는 내 이동 좌표를
/game/13/move/1
그리고 나서 얻을 것입니다
/game/13/move/2
서버는 즉시 응답하지 않지만 다른 플레이어가 움직일 때까지 연결을 계속 열어 놓습니다 (즉, 해당 위치에 넣습니다). 이것이 Nakajima가 "Comet-esque"라고 말하는 것입니까?
찰리, 나는 당신이 "토큰"이 누구의 차례인지 확실하지 않습니다. 이것은 투표 나 차단 연결없이 동일한 문제를 해결합니다.
플레이어 ID의 경우 URL의 일부에서 리소스로 모델을 모델링하는 것이 합리적입니까? HTTP 사용자 인증을 간단히 사용할 계획이었습니다 (사용자/패스가 모든 요청의 일부로 전송되는 경우). 여전히 인증없이 대부분의 리소스를 얻을 수 있지만, 예를 들어,
PUT /game/13/move/2
해당 게임에 대한 올바른 자격 증명이없는 경우 허가 거부 오류가 제공됩니다.
좋아, 휴식의 기본 아이디어는 당신이 상태를 양도하고 있다는 것입니다. 서버에 "세션 상태"가 거의 없거나 전혀 없으려고합니다. 그래서 당신은 세션 상태와 keepalive를 사용하고 싶지 않을 것입니다. 이것이 혜성이하는 일입니다. 그러나 게임 별 게임의 예에 대해 생각해보십시오. 둘 다 보드의 사본이 있고 이동을 교환합니다. 우체국은 게임에 대해 모른다.
자, 나는 이것이 내가 생각하면서 내 마음 속에서 성장하고 있음을 인정할 것입니다. 사실, 나는이 질문에 기반한 기사를 쓸 수 있습니다. 그러나 여기에 아이디어가 있습니다.
- 당신은 라인에서 체스 게임을하고 싶어서 알려진 URI로 가서 하나를 얻습니다. 당신은 누군가가 게임을 시작하기를 기다리는 사람을 보여주는 페이지를 다시 얻습니다.
- 플레이를 기다리는 사람들 중 하나를 선택하고 적절한 링크를 클릭하십시오. 보드가 설정된 새로운 디스플레이 (원하는 경우 여기에 Ajax Magic)를 얻을 수 있습니다. 당신 중 하나는 흰색이고 흰색이 먼저 움직입니다.
- 이사 할 권리가있는 사람은 이동에 들어가서 게임에서 손을 떼는 것과 같이 커밋합니다. 보드가 업데이트되고 이동 권리는 다른 플레이어에게갑니다.
서버 상태 측면에서 아무것도 필요하지 않습니다. 비록 이동 등을 추적함으로써이를 확장하고 싶을 수도 있지만 순위를 높이십시오. 보드 페이지 : 권리가있는 경우 이동을위한 양식이 있습니다. 양식 반환을 다시 보낼 때 응답은 이동을위한 슬롯없이 페이지를 반환합니다.
"Token"에 의해 나는 단지 그 상태의 "My Move"/"Your Move"를 임의의 표현을 의미합니다.
필요한 자원이있는 것처럼 보입니다
- "게임 찾기"홈페이지
- 통계 등을 추적하는 경우 사용자 페이지
- 모든 활성 게임에 대한 독특한 URI.
고마워요, 찰리. 나는 당신이 당신의 계획에서 상대방의 움직임에 대해 어떻게 통보받는 지 아직도 명확하지 않습니다. 물론 이동 권리가있는 사람에 대한 질문은 보드 리소스에서 나오는 또는 전환 할 것을 명시 적으로 말하는 별도의 리소스를 사용하여 간단하게 계산할 수 있습니다. 그러나 고객은이 자원이 변경되었다는 것을 어떻게 알 수 있습니까? 무언가가 바뀌었을 때까지 이전 상태를 기억하면서 단순히 지속적으로 설문 조사를해야합니까? 우체국 모델에서 우체국은 HTTP에서는 불가능한 클라이언트 (사서함)에게 메시지를 "푸시"합니다.
나는 이것이보다 일반적인 질문의 일부라고 생각합니다. 변경 또는 수정을 모니터링하려는 REST 리소스가 있다면 가장 좋은 방법은 무엇입니까? 그리고 서버가 클라이언트를 쉽게하기 위해 할 수있는 일이 있습니까?
나는 그 자체로 흥미 롭다고 생각하기 때문에 실제로 이것을 별도의 질문으로 게시 할 것이라고 생각합니다.
추가하기 위해 편집 : 변경 사항에 대한 휴식 자원을 모니터링하는 편안한 방법은 무엇입니까?
나는 REST가 그러한 응용 프로그램에 좋은 선택이라고 생각하지 않습니다. 당신이해야 할 변형과 운영 (움직이고, 이동 기록보기, 실행 취소, 제안 받기, 알림 턴)는 REST의 자원 개념에 깔끔하게 매핑되지 않습니다. (스크래블이나 독점과 같은 더 복잡한 턴 기반 게임에 대한 편안한 API가 어떻게 보이는지 고려하면 어려움이 더 분명 할 것입니다.)
나는 현명한 REST API가 아마도 보낸 상태의 프로토콜과 같이 비 퇴사적 인 무언가를 중심으로 래퍼가 될 것이라고 생각합니다. 휴대용 게임 표기법 이리저리.
나는 당신이 할 수 있다고 생각합니다 모델 편안하게. 구현 필요하기 때문에 더 어려울 것입니다. 혜성)-esque 솔루션 또는 Ajax를 통해 비교적 짧은 간격으로 서버를 폴링해야합니다.
편안한 인터페이스를 노출시키는 방법과 관련하여 좌표가있는 플레이 보드, 해당 좌표를 차지할 수있는 조각 및 좌표를 변경하는 동작이 필요하다고 말합니다.
플레이어가 움직일 때 새로운 조치가 만들어집니다. 허용되는지 확인한 후 게임 상태를 업데이트 한 다음 UI를 업데이트하는 데 필요한 응답을 렌더링합니다.
그래서 기본적으로 내가 모델링하는 방식입니다. 구현 측면은 내가 여기서 더 큰 어려움을 고려하는 것입니다.
나는 그것이 합법적 인 전부라고 생각하지 않습니다, Nakajima. 당신은 JSON에서, 보드 위치, 움직임을 위해, 그리고 다음 움직임을 가진 사람에 대한 토큰과 데이터를 전달합니다. 우편으로 플레이하는 것과 똑같습니다.
당신은 게임에 가서 파트너를 찾는 것으로 시작합니다.
/game/
기다리는 사람들의 목록을 제공합니다. 당신이 들어올 때, 아무도 기다리지 않으면 당신은 게임 ID를 얻습니다. 그렇지 않으면 당신은 누군가를 대기하고 그들이 가진 게임 ID를 얻습니다.
/game/gameID
보드를 보여줍니다. 당신은 누가 백인을 연기하는 결정을 설정하기 위해 무언가가 필요합니다. 나는 그것을 연습으로 남겨 둘 것입니다. Get Operation은 보드를 제공하므로 게시물은 이동을 보냅니다. 움직이지 않으면 오류가 발생합니다. 다음 Get은 결과를 찾습니다.
지옥에서,이 모델에서는 게이머 ID조차 사용하지 않지만 아무도 Kibitzer로 게임에 몰래 들어갈 수 없을 수도 있습니다.
그래서 당신의 생각은 행동을 일류 대상으로 만드는 대신 게임 자체의 업데이트로 취급 될 것입니까? 나는 다른 방법이지만, 나는 몇 가지 이유로 액션 객체를 자체 일류 엔터티로 나누는 것을 선호한다고 생각합니다. 가장 큰 이유는 내가 더 테스트 가능하다고 생각하기 때문입니다. 이동이 유효한지 여부는 보드가 항상 유효한 상태에있는 것에 대해 걱정할 필요가있는 대신 액션 객체에 살 수 있습니다. 물론, 나는 어떤 접근법이 어떤지에 어떤 영향을 미칠지 모르겠지만, 이것은 나에게 기분이 좋아집니다.
Yagni를 통해 완전히 반박 할 수있는 다른 이유는 첫 번째 집단 행동 객체가 동작의 역사를 제공하기 때문입니다. 아마도 흥미롭지 만 요구 사항이 아니라면 뮤트 포인트입니다.
개발자 중 하나 Planet.jabber 관여합니다 체스 파크, 온라인 체스 커뮤니티. 그들은 Jabber/XMPP를 광범위하게 사용하고 있습니다. 내가 틀리지 않는 경우, 이것들은 주제에 대한 그의 게시물입니다.
XMPP는 대략 소형 XML 메시지 교환을 기반으로하는 인스턴트 메시징 프로토콜입니다. 대부분의 언어에 대한 라이브러리가 있습니다. 포함 자바 스크립트. 그래도 그것이 당신의 문제에 맞는지 확실하지 않습니다.
체스와 같은 간단한 게임의 경우 실제로는 미디어 유형을 정의하는 것뿐입니다.
다음은 체스 게임을 모델링하기 위해 지나치게 단순화된 미디어 유형의 예입니다.
동일한 서버에서 실행될 수 있는 여러 게임의 관리를 건너뛰고 이미 실행 중인 게임만 모델링하겠습니다.
첫 번째 단계는 일반적으로 애플리케이션에 대한 인덱스를 정의하는 것입니다.
index
게임의 진입점입니다.게임에 대한 정보를 찾으려면 이것을 가져오세요.
페이로드는 다음과 같습니다.
{
"links": {
"self": "http://my-chess-game.host/games/123",
"player": "http://my-chess-game.host/players/1",
"player": "http://my-chess-game.host/players/2",
"me": "http://my-chess-game.host/players/1",
...
}
"board": [
{
"x": 0,
"y": 1,
"piece": null,
"rel": "space",
"href": "http://my-chess-game/.../boards/123/0/1/something-random-to-discourage-uri-construction"
},
{
"x": 1,
"y": 2,
"rel": "space",
"href": "...",
"piece": {
"player": "http://my-chess-game/.../players/1",
"type": "http://my-chess-game/pieces/Bishop",
"rel": "piece",
"href": "http://my-chess-game/games/123/pieces/player1/Bishop/1",
"links": [
{ "rel": "move": "href": "http://my-chess-game/.../boards/123/..." },
...
]
}
},
...
]
}
move
다음으로 표시된 링크에 JSON 페이로드를 게시합니다. rel ~의 move 조각을 이동합니다.다음 필드가 포함되어야 합니다.
- 위치:이동할 공간의 URI
성공적인 응답의 상태 코드는 200이며, 응답과 동일한 엔터티를 포함합니다. index 업데이트된 게임 상태가 포함된 페이로드.
사용자가 자신의 작품을 그곳으로 옮기는 것이 허용되지 않거나 자신의 차례가 아닌 경우 400입니다.
player
플레이어에 대한 설명을 가져옵니다.
응답에는 다음 필드가 있어야 합니다.
- 사용자 이름:플레이어의 사용자 이름
- href:이 게임의 플레이어를 식별하는 URI입니다.
piece
조각이 내장되어 있습니다. index 페이로드이지만 그 자체로 존재할 수도 있습니다.각 piece 다음 필드가 있어야 합니다.
- 유형:작품의 유형을 식별하는 URI입니다.예를 들어비숍, 루크, 킹.이 URI를 얻으면 이 작품이 체스 게임 내에서 어떻게 작동하는지에 대한 정보를 제공할 수 있습니다.
- href:이 보드의 실제 작품을 식별하는 URI입니다.이 URI에 대한 GET 요청은 이 특정 부분에 대한 정보를 제공할 수 있습니다.
각 작품에는 다음이 있어야 합니다. move 링크.
여기서 제가 내릴 수 있는 대안적인 디자인 결정은 모든 유효한 움직임에 대해 개별 링크를 제공하는 것이었습니다.그렇게 하는 데에는 타당한 이유가 있을 수 있지만 반드시 그럴 필요는 없다는 것을 보여주고 싶었습니다.고객이 누구의 차례인지, 무엇을 할지 결정하도록 돕는 것과 같은 일을 처리하기 위해 포함하고 싶은 다른 리소스가 몇 가지 있을 수 있습니다.
Civilization, RTS, FPS 또는 MMOG와 같은 더 복잡한 게임의 경우 이는 그다지 실용적인 IMO가 아닐 수 있습니다.
