RESTful для HTTP PATCH обновлять больше, чем явно предоставленные, во время запроса, поля

Question

Мне интересно, можно ли разработать RESTful API для игры в ti c ta c toe. Я хочу предоставить пользователям возможность создавать новые игры, делать ходы, а также сделать запрос на участие ИИ в игре.

В настоящее время у меня есть

POST /users/{id}/games

With Response
{
    "id": 1,
    "board": "_________",
    "nextPlayer": "X",
    "movesLeft": [0, 1, 2, 3, 4, 5, 6, 7, 8],
    ...
}

имеет смысл предоставить опцию «разместить ход», например, такую:

PATCH /users/{id}/games/1
{
    "board": "____X____"
}

Если я выдаю запрос PATCH, предоставляя только новую доску, можно ли серверу сохранить это, удалите значение из свойства MoveLeft, измените, кто является nextPlayer, и т.д. это основано на бизнес-логике c?

Также, RESTful выставить конечную точку:

POST /users/{id}/games/1/ai/moves

, которая в основном делает ход на доске, меняет все соответственно, возвращает 303 См. Другое и делает заголовок Location в заголовках ответа, чтобы указать на измененный игровой ресурс - / возможно, даже немедленно возвращает измененную игру /

Я был бы очень признателен за любые ссылки, источники, b записи в журнале, примеры

Answer 1

Является ли RESTful для запроса PATCH, чтобы он не включал в себя все, что необходимо изменить, однако сервер должен изменить его на основе бизнес-логики c?

В общем, да , HTTP - это соглашение о семантике сообщений (см. Fielding 2002 ). PATCH , как PUT , означает «сделать вашу копию похожей на мою копию».

Вы хотите быть немного осторожнее с ответом, чтобы не подразумевать, что запрошенная изменения были приняты «как есть», если на самом деле сервер также внес изменения в документ без запроса. Другими словами, клиент будет иметь свое представление ресурса в памяти, и мы хотим, чтобы в ответе было ясно, является ли это представление по-прежнему точным.

Является ли это RESTful для предоставления конечной точки POST /users/{id}/games/1/ai/moves, который в основном делает ход на доске, соответственно меняет все, возвращает 303 См. Другое ...

Это немного слабо. Проблема в аннулировании кэша . Если я клиент общего назначения , как я узнаю, что мое кэшированное представление /users/{id}/games/1 становится недействительным, когда я успешно отправлю POST на /users/{id}/games/1/ai/moves - мне нечего сказать, что эти два ресурса связаны друг с другом.

Вместо этого мы обычно делаем POST-сообщение "make ai move" для /users/{id}/games/1. Теперь клиент общего назначения, а также любые промежуточные компоненты будут знать, что представление самого игрового ресурса было изменено и должно быть обновлено.