Necesito una idea para una implementación RESTful del API de inventario para un juego de rol

Question

Estoy trabajando en una especie de juego de rol. Y estoy tratando de averiguar una forma agradable, limpia y RESTful de definir API de inventario.

inventario se compone de varios slots como , chest etc. (como en la mayoría de los juegos de rol).

ahora tengo que definir REST API para mover todos los elementos de la ranura X a Y. ranura

algunas ideas que tenía:

• así, obviamente, las vidas de inventario en /inventory
• por lo 1st La idea era tener algo como /inventory/movement y tener un CREATE en eso para que sea CRUD. entonces será POST /inventory/movement. esto será CRUD y REST, pero se siente muy mal.
• otra era para tener algunos atributos mágicos en el inventario y simplemente actualizar en él: PUT /inventory?move_from=A&move_to=B. Esto todavía no se siente muy bien.

so .. alguna idea para una solución CRUD REST limpia para esto?

ACTUALIZACIÓN: acabo de tener otra: PUT /inventory/:to_slot?from=:from_slot - todavía no estoy seguro. ¿Por qué está la acción en solo una ranura cuando 2 están involucrados? Hmm ... ugh!

Answer 1

Dado que en REST siempre debe actuar sobre un recurso o sobre una colección de recursos, en este caso consideraría la acción 'MOVE' como el recurso REST. Esto puede parecer incorrecto al principio, ya que consideramos que 'MOVE' es un verbo y no un sustantivo, pero esto puede tener sentido si la interfaz cubre un alto nivel de abstracción. En una interfaz de alto nivel que expone las opciones disponibles para que el usuario controle el juego, es posible que desee actuar sobre la 'MOVE OPTION', que de repente se convierte en un sustantivo.

que sería, por tanto, utilizar el verbo POST para mover un elemento dentro del inventario, ya que estarían emitiendo una solicitud para crear un nuevo 'MOVER' acción. Consideremos los siguientes ejemplos explican por sí mismos:

- POST /move/inventory/a/b 
- POST /sell/inventory/a 
- POST /use/inventory/b 

El 'MOVER' mando en operaciones CRUD primas normalmente se implementa con un CREATE seguido por un DELETE. Sin embargo, creo que sería demasiado bajo si usara operaciones crudas de CRUD en recursos de juegos como ese.

Si tuviera que OBTENER un elemento de x y PONERLO en y, ¿dónde colocaría la lógica de validación que verifica si y es un destino válido? ¿Debería estar en el modelo (detrás de la interfaz) o dentro de tu juego? Si debería estar en el modelo, entonces creo que debería considerar el enfoque de alto nivel que describí anteriormente. Si, por otro lado, tiene la intención de manejar esta lógica dentro del juego (en frente de la interfaz), entonces puede tomar el enfoque crudo CRUD, como Jan suggested in another answer.

Tenga en cuenta que si su RPG va a estar orientado a la web, es imperativo que maneje la lógica del juego en el lado del servidor.En ese caso, trataría de mapear la interfaz REST uno a uno con los controles y opciones que se le solicitaron al usuario, y, de nuevo, sugeriría el modelo de alto nivel propuesto anteriormente.

Answer 2

Debe actualizar un position_id de un elemento ipotetic dentro de la lógica del dominio, o algo similar ¿no?

por lo que creo que shuld puestos para el elemento existente:

PUT /items/:id?position_id=:position_id 

muestra:

PUT /items/1?position_id=2 

Ya conoce la "posición de" porque ya debería estar definido en su ISN modelo de elemento no es así?

, por supuesto, se puede añadir el/inventario/espacio de nombres si te gusta para que sea más descriptivo, por lo que sugiero:

PUT /inventory/items/:id?position_id=:position_id 

P. S. Tenga en cuenta que los parámetros después de? no son parámetros GET :)

Answer 3

Vitaly,

no piensan en términos de acciones (mover a), pero en términos de recursos y transferencia de estado. Así es como yo haría lo que piden con DESCANSO:

 
GET /game/inventories/5536 

200 Ok 
Content-Type: application/rpg.inventory+xml 

<inventory> 
    <slot href="/game/inventories/5536/slot">X</slot> 
    .... 
</inventory> 





PUT /game/inventories/5536/slot 

Content-Type: text/plain (or what you need) 

"Y" 

GET /game/inventories/5536 

200 Ok 
Content-Type: application/rpg.inventory+xml 

<inventory> 
    <slot href="/game/inventories/5536/slot">Y</slot> 
    .... 
</inventory> 

pero puede haber otras maneras también.

Ene

Answer 4

Debido a que el inventario es sólo un hash en un modelo de personaje, que puede llegar a funcionar con descriptores de acceso personalizados para cada uno de sus ranuras importantes que modifican el hash según sea necesario.

La medida ideal desde la ranura de A a B puede ser algo como

PUT /inventory with params: 

{inventory => {:worn_on_head => nil, :worn_on_left_arm => @item}} 

usted podría simplificar los parámetros con validaciones y llamar a la espalda o incluso utilizar los descriptores de acceso a ellos para asegurar que el mismo artículo no está en múltiples ranuras Esencialmente acortar los parámetros para una solicitud de movimiento a algo como:

PUT /inventory with params: 

{:inventory => {:worn_on_left_arm => @item}} 

Una apuesta segura es sólo tirar un error de validación, si un usuario trata de equipar a más copias de un elemento de lo que tienen, sin tener que reemplazar una de la otra unos en el momento del cambio.