Что УСПОКОИТЕЛЬНЫЙ API Вы использовали бы для основанного на повороте игрового сервера?
Вы можете просто случайным образом выбрать каждую букву в старой строке, если вы должны использовать строчные или прописные буквы, например:
import random
def myfunc2(old):
new = ''
for c in old:
lower = random.randint(0, 1)
if lower:
new += c.lower()
else:
new += c.upper()
return new
9 ответов
Каковы ресурсы, которые Вы пытаетесь смоделировать? Я, казалось бы, имел бы четыре: Вы, Ваш противник, конкретная игра (сессия, экземпляр) и состояние игровой доски. Таким образом, это запустилось бы с чего-то как
/game
/game/gameID/gamer/gamerID
/game/gameID/board
у нас есть хорошее введение/обзор на InfoQ.
Я думаю что-то как:
/game/<gameID>/move/<moveID>
насколько основные ресурсы затронуты. Я не уверен, как обработать "другой плеер, переместился уже?" идея, все же. Я думал о простом наличии ПОЛУЧИТЬ блока запроса, пока перемещение не играется - т.е. мой клиент ПОМЕСТИЛ бы координаты моего перемещения к
/game/13/move/1
и затем ДОБРАЛСЯ бы
/game/13/move/2
Сервер сразу не ответил бы, но сохранил бы соединение открытым до другого плеера перемещенный (т.е. Помещенный в то местоположение). Это то, что nakajima называет "кометой-esque"?
Charlie, я не совсем уверен, что Вы подразумевали под "маркером", для поворота которого это - это решает ту же проблему без потребности в опросе или блокирующемся соединении?
Для идентификаторов плеера имеет смысл моделировать тех как ресурс в части URL? Я планировал просто использовать аутентификацию Пользователя HTTP (куда пользователь/передача отправляется как часть каждого запроса). Вы могли все еще ПОЛУЧИТЬ большинство ресурсов без аутентификации, но если Вы пытались, скажем,
PUT /game/13/move/2
это дало бы Вам, разрешение отклонило ошибку, если у Вас не было корректных учетных данных для той игры.
Хорошо, основная идея о REST состоит в том, что Вы передаете состояние; Вы хотите иметь минимальное "состояние сеанса" на сервере. Таким образом, Вы не хотели бы использовать состояние сеанса и проверку активности, которая является тем, что делает Комета. Но думайте о примере игры игры почтой: у Вас обоих есть копия платы, и Вы обмениваетесь перемещениями. Office The Post не знает об игре.
Теперь, я признаю, что это растет в моем уме, как я думаю об этом - на самом деле, я могу написать статью на основе этого вопроса - но здесь являюсь идеей как некоторые истории:
- Вы хотите играть в игру шахмат на строке, таким образом, Вы переходите к известному URI для получения того. Вы возвращаете страницу, показывающую, кто, если кто-либо, ожидает для запуска игры.
- Вы выбираете одного из людей, ожидающих, чтобы играть, и нажать на соответствующую ссылку. Вы получаете новый дисплей (ajax волшебство в здесь, если Вы хотите) с набором плат. Один из Вас является белыми, белыми перемещениями сначала.
- Кто бы ни имеет право переместиться, вводит перемещение и фиксации (как взятие Вашей руки от части в игре.) Обновления платы и право переместиться переходит к другому плееру.
Вам ничто не нужно очень с точки зрения сервера, указывают---, хотя Вы могли бы хотеть расширить это путем отслеживания перемещения и т.д., сказать для рейтинга - и вопрос того, кто имеет право переместиться, может быть вычислен полностью из страницы платы: если Вы имеете право, у Вас есть форма для ввода перемещения; при передаче возврата формы обратно ответ возвращает страницу Вам без слота для ввода перемещения.
"Маркером" я просто имею в виду некоторое произвольное представление того одного бита состояния "Мое перемещение" / "Ваше перемещение".
Кажется, как будто ресурсы, в которых Вы нуждаетесь,
- "Находят игру" домашней страницей
- Пользовательская страница, если Вы отслеживаете статистику и такой
- уникальный URI для каждой активной игры.
Спасибо, Charlie. Я все еще не ясен, как Вы уведомляетесь относительно перемещения противника в своей схеме. Конечно, вопрос того, кто имеет право переместиться, может быть вычислен просто - или из ресурса платы, или при помощи отдельного ресурса, который явно указывает, чей поворот это должно переместить. Но как клиент знает, что этот ресурс изменился? Это должно просто постоянно опрашивать, помня предыдущее состояние, пока это не замечает, что что-то изменилось? В модели Post Office Почтовое отделение "продвигает" сообщение клиенту (Ваш почтовый ящик), который не возможен в HTTP.
Я предполагаю, что это - часть более общего вопроса: если существует ресурс REST, который я хочу контролировать для изменений или модификаций, что лучший способ состоит в том, чтобы сделать так? И есть ли что-то, что сервер может сделать для создания этого легче для клиента?
Я думаю, что на самом деле отправлю это как отдельный вопрос, так как я думаю, что это интересно отдельно.
Отредактированный для добавления: Что такое УСПОКОИТЕЛЬНЫЙ способ контролировать ресурс REST для изменений?
Я думаю, что Вы могли смоделировать его УСПОКОИТЕЛЬНО. Реализация его будет более трудной, потому что Вам или была бы нужна комета)-esque решение, или необходимо будет опрашивать сервер в относительно коротком интервале через Ajax.
С точки зрения того, как Вы выставили бы интерфейс RESTful, я скажу, что Вам нужна плата проигрывания с координатами, части, которые могут занять те координаты и действия, которые изменяют те координаты.
Когда плеер делает перемещение, новое действие было бы создано. После проверки для проверки это позволяется, Вы обновили бы состояние игры, затем представили бы любой ответ, необходим для обновления UI.
Таким образом, это в основном, как я смоделировал бы его. Сторона реализации - то, что я рассмотрел бы большей трудностью здесь все же.
Я не думаю, что это - все, что это усложнило, Nakajima. Вы передали бы данные, сказали бы в JSON, для позиции платы, для перемещений, и с маркером для того, у кого есть следующее перемещение. Это было бы точно похоже на проигрывание почтой.
Вы запускаете путем движения в игру и поиска партнера, таким образом,
/game/
дает Вам список людей, ожидающих. когда Вы входите, если нет никакого ожидания, Вы получаете игровой идентификатор; иначе Вы выбираете кого-то ожидание и получаете игровой идентификатор, который они имеют.
/game/gameID
шоу Вы плата. Вам нужно что-то для установки решения того, кто играет белый, я оставлю это как осуществление. ПОЛУЧИТЬ операция дает Вам плату, таким образом, POST отправляет перемещение; если у Вас нет перемещения, Вы получаете ошибку. Вы находите, что результат следующим ДОБИРАЕТСЯ.
Черт, в этой модели я даже не использую идентификатор геймера, хотя это могло бы быть хорошо, таким образом, никто не может красться в игру как kibitzer.
Таким образом, Ваша мысль - то, что вместо того, чтобы делать действия объектом первого класса, каждое перемещение рассматривали бы как обновление самой игры? Это - конечно, другой способ сделать это, хотя я думаю, что предпочел бы разделять объект действия на его собственный объект первого класса по паре причин. Самая большая причина состоит в том, что я полагаю, что это является более тестируемым. Допустимо ли перемещение, мог бы жить в объекте действия, вместо того, чтобы должным быть волноваться о плате, находящейся в допустимом состоянии в любом случае. Предоставленный, я не знаю то, что повлек бы за собой любой подход, но это чувствует себя лучше мне.
Другая причина, которую можно полностью опровергнуть через YAGNI, состоит в том, что объект действия первого класса предоставил бы историю перемещений. Интересный, возможно, но если требование, не спорный вопрос.
Один из разработчиков в planet.jabber привлечен в Chesspark, шахматное сообщество онлайн. Они используют Jabber/XMPP экстенсивно; если я не ошибаюсь, это его сообщения на предмете.
XMPP является протоколом мгновенного обмена сообщениями, примерно на основе маленького обмена сообщения XML. Существуют библиотеки для большинства языков, включая JavaScript. Я не уверен, что это будет соответствовать Вашей проблеме, все же.
Я не думаю, что REST - хороший выбор для такого приложения. Преобразования и операции, которые вам необходимо выполнить (перемещение, просмотр истории перемещений, отмена, получение предложения, уведомление о повороте), не соответствуют концепции ресурсов REST. (Трудности, возможно, станут более очевидными, если учесть, как может выглядеть RESTful API для более сложных пошаговых игр, таких как Scrabble или Monopoly.)
Я думаю, что любой разумный REST API, вероятно, окажется оберткой вокруг чего-то не- RESTful, например протокол с отслеживанием состояния, который отправлял переносимую игровую нотацию туда и обратно.