캐릭터가 다른 대상과 캐릭터에 대해 복잡한 동작을 수행 할 수있는 온라인 게임을 개발 중입니다. 나는 REST API를 구축하고 있으며 가장 기본적인 표준조차도 따르려고 많은 어려움을 겪고있다. REST가 항상 답이되는 것은 아니라는 점을 알고 있지만, API의 나머지 부분에서 REST를 적절하게 사용하므로 REST를 사용하는 것이 여러 가지 이유에서 유용합니다.REST에서 복잡한 연산을 어떻게 모델링합니까?
GET/문자/밥/항목 이 밥이 수행되는 항목의 배열을 반환
는 여기에 몇 가지 까다로운 예입니다.
이 항목들에 대해 다양한 '작업'을 수행해야하며이를 '자원'으로 모델링하는 데 매우 어려움을 겪고 있습니다. 여기
는 항목의 특성에 따라 몇 가지 잠재적 인 작업입니다 던져, 드롭, 먹는이 '작업'특정 항목에만 적합하기 때문이 복잡 누르고 있습니다. 예를 들어 칼을 먹을 수는 없습니다. 더욱이, '먹는 것'은 본질적으로 자원을 '삭제'하는 부작용이 있습니다. 'throw'를 사용하면 리소스를 '삭제'할 수도 있습니다. 'drop'을 사용하면 리소스를 다른 리소스 유형으로 '변환'할 수 있습니다. '던지다'는 '위치'를 제공해야합니다. '보류'를 선택하면 항목을 보유 할 손을 제공해야합니다. 그러면 이러한 작업을 자원으로 어떻게 모델링합니까? 그들 각각은 서로 다른 매개 변수를 필요로하고 전혀 다른 행동을하기 때문에 '모두 비슷합니다'는 없습니다.
현재 이러한 임의의 작업을 POST하는 'actions'리소스가 있습니다. {: 5, 해당 itemId : 10, X : 100, Y : 150 characterId}
나는이 접근 방식을 이해하고 있는지 잘 모르겠습니다. '상태'/ '표현'/ '리소스'는이 유형의 POST로 수정합니까?이것은 쿼리 매개 변수가 궁극적으로 예상되는 POST의 '스키마'를 지정하기 때문에 RPC와 같습니다. – user43823
리소스가 사용중인 개체 (수정중인 개체)입니다. action 매개 변수를 쿼리로 생각하지 마십시오. 대체 동사로 생각합니다. HTTP/REST는 동사 EAT를 제공하지 않지만 action = eat은이를 모델링하려고합니다. 복잡한 다중 리소스 메시지는 모델링하기가 어렵다고 생각합니다. 나는 "POST/actions/throw"가 나에게 RPC와 같은 것처럼 보일 것이라고 말한다. –
@MikeDunker : 새로운 동사를 생성하는 대신에 자원 (수집)'식사'와'먹는'과'POST' 새 항목을 만들 수 있습니다 :'{item : X}'와 함께'POST/characters/bob/eatings' . 아니면 좀 더 일반적인'operations' 리소스를 만들고'{name : 'eat', item : X}'를 사용하여'POST/characters/bob/operations'를 만들 수 있습니다. – marcinn