Мне нужна идея для УСПОКОИТЕЛЬНОЙ реализации API материально-технических ресурсов для игры RPG
Я работаю над видом игры RPG. И я пытаюсь выяснить хороший, чистый и УСПОКОИТЕЛЬНЫЙ способ определить API материально-технических ресурсов.
материально-технические ресурсы состоят из нескольких slots как head, chest и т.д. (как в большинстве игр RPG).
Теперь я должен определить API REST для перемещения всех объектов от слота X до слота Y.
немного идей я имел:
- хорошо, очевидно, материально-технические ресурсы живут в
/inventory - таким образом, 1-я идея состояла в том, чтобы иметь что-то как
/inventory/movementи иметь aCREATEна этом для создания егоCRUD. таким образом, это будетPOST /inventory/movement. это будет CRUD и REST, но он чувствует себя очень плохо. - другой должен был иметь некоторые волшебные атрибуты на материально-технических ресурсах и просто сделать обновление на нем:
PUT /inventory?move_from=A&move_to=B. Это все еще не чувствует себя слишком хорошо.
так.. какая-либо идея для чистого решения для REST CRUD для этого?
ОБНОВЛЕНИЕ: просто имел другой: PUT /inventory/:to_slot?from=:from_slot - не уверенный все еще. почему состоит в том действие со всего одним слотом, когда 2 включены? хм... тьфу!
4 ответа
Я предпочитаю использовать ссылки, поскольку они были введены для неуправляемого C++ в VS 2005. Отличие (в ракурсе разработчика неуправляемого C++) состоит в том, что ссылка хранится в файле .vcproj , а зависимости проекта - в файле .sln .
Это различие означает, что при повторном использовании проекта в различных решениях (и я часто это делаю) вам не нужно заново определять межпроектные отношения.
Visual Studio достаточно умна, чтобы не сильно зависеть от путей проектов при установлении ссылочного отношения.
-121--2953925- Используйте так называемый LinkedResource . Здесь можно найти инструкции. Сделали это успешно.
Если учебник не помогает, не стесняйтесь и просите разъяснения.:)
-121--3586906-Так как в REST вы всегда должны действовать на ресурс или на коллекцию ресурсов, в этом случае я бы рассматривал действие ' MOVE ' как ресурс REST. Сначала это может выглядеть неверно, так как мы считаем ' MOVE ' глаголом, а не существительным, но это может иметь смысл, если интерфейс охватывает высокий уровень абстракции. В высокоуровневом интерфейсе, который предоставляет пользователю опции, доступные для управления игрой, вы можете действовать на ' MOVE OPTION ', который внезапно становится существительным!
Поэтому я бы использовал команду POST для перемещения предмета в пределах запаса, так как мы бы отправили запрос на создание нового действия ' MOVE '. Рассмотрим следующие пояснительные примеры:
- POST /move/inventory/a/b
- POST /sell/inventory/a
- POST /use/inventory/b
Команда ' MOVE ' в необработанных операциях CRUD обычно реализуется с командой CREATE, за которой следует DELETE. Тем не менее, я думаю, что вы сочтете его слишком низким, если будете использовать необработанные операции CRUD для таких игровых ресурсов.
Куда бы вы положили логику проверки, которая проверяет, является ли y допустимым местом назначения? Должен ли он быть в модели (за интерфейсом) или в вашей игре? Если это должно быть в модели, то я думаю, что вы должны рассмотреть подход высокого уровня, который я описал ранее. Если, с другой стороны, вы намерены обработать эту логику в игре (перед интерфейсом), то вы можете использовать необработанный CRUD подход, как Ян предложил в другом ответе .
Обратите внимание, что если ваш RPG будет ориентирован на веб-интерфейс, необходимо, чтобы вы обрабатывали игровую логику на стороне сервера. В этом случае я хотел бы сопоставить интерфейс REST один к одному с элементами управления и опциями, предложенными пользователю, и, опять же, я бы предложил модель высокого уровня, предложенную выше.
Он должен обновить position_id ipotetic Item внутри логики домена, или что-то подобное, не так ли?
поэтому я думаю, вы должны PUT в существующий элемент:
PUT /items/:id?position_id=:position_id
образец:
PUT /items/1?position_id=2
вы уже знаете "позиция из", потому что она уже должна быть определена в вашей модели элемента, не так ли?
конечно, вы можете добавить пространство имен / inventory /, если хотите сделать его более наглядным, поэтому я предлагаю:
PUT /inventory/items/:id?position_id=:position_id
ps обратите внимание, что параметры после? не являются параметрами GET :)
Поскольку инвентарь - это просто хэш в модели персонажа, вы можете обойтись настраиваемыми аксессуарами для каждого из ваших важных слотов, которые изменяют хеш по мере необходимости.
Перемещение RESTful из слота A в B может быть чем-то вроде
PUT /inventory with params:
{inventory => {:worn_on_head => nil, :worn_on_left_arm => @item}}
Вы можете потенциально упростить параметры с помощью проверок и обратных вызовов или даже использовать сами аксессоры, чтобы гарантировать, что один и тот же элемент не находится в нескольких слотах. По сути, сокращение параметров запроса на перемещение до следующего вида:
PUT /inventory with params:
{:inventory => {:worn_on_left_arm => @item}}
Более безопасная ставка - просто выдать ошибку проверки, если пользователь попытается оснастить больше копий предмета, чем они имеют, без замены одной из других одновременно изменений.
Виталий,
думайте не в терминах действий (move-to), а в терминах ресурсов и передачи состояния. Вот как я бы сделал то, о чем вы спрашиваете, с помощью REST:
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>
Но могут быть и другие способы.
Jan