Ongoing API changes

[CrsiX]

Whenever the API changes, a little notice in this discussion would be helpful to keep track of them.

[myOmikron]

GET /friends: Split output

[CrsiX]

Acknowledged.

[myOmikron]

POST /friends/request -> POST /friends

[CrsiX]

Acknowledged.

[myOmikron]

POST /friends/{id} -> PUT /friends/{id}

[CrsiX]

Acknowledged.

[myOmikron]

Added GET /admin/health

[CrsiX]

Acknowledged.

[myOmikron]

Added GET /lobbies

[CrsiX]

Acknowledged.

[myOmikron]

Added POST /lobbies

[CrsiX]

Acknowledged.

[myOmikron]

Updated GET /lobbies AND POST /lobbies

[CrsiX]

Acknowledged.

[CrsiX]

Require endpoint to start game from lobby, e.g. POST /api/v2/lobby/startGame for the creator/owner of the lobby

[CrsiX]

See #9

[CrsiX]

Require load game data via REST API (e.g. GET /api/v2/games/{game_id}) if the user is part of the game

[CrsiX]

Implemented.

[CrsiX]

Request invites to open lobbies which can be sent to friends

[CrsiX]

Seems to be implemented already.

[CrsiX]

Request endpoint to know in which chat room(s) a user currently is (list of UUIDs is sufficient)

[myOmikron]

implemented, GET /chats

[CrsiX]

Thanks

[CrsiX]

1. Request endpoint to start a lobby which at least returns an already allocated and therefore valid game UUID, so that pushing new game states for that UUID becomes possible. This will be used during game creation.

2. Request to switch from game IDs (i64) to game UUIDs, since they are used internally at the client already. This doesn't affect other game values, like the game data identifier (state ID).

[CrsiX]

See #10

[CrsiX]

Here's an example value (36 bytes): e25vdGU6VGhpcyBpcyBhbiBleGFtcGxlfQo=
But we should also add a comment that it's base64-encoded, gzipped game data as JSON.

[CrsiX]

See #11

[CrsiX]

To Do: /api/v2/friends returns for unknown UUIDs:

{
  "message": "Invalid username",
  "status_code": 1009
}

Change to "unknown UUID" or introduce a new field for that?

[CrsiX]

See #15

[CrsiX]

To Do: /api/v2/friends should have a notice that in the friends list, I am always the from field and this should be asserted by the server code. This way, the client can just drop the from part and just use the to part to know the friends.

[CrsiX]

See #12

[CrsiX]

To Do: Doing a POST /api/v2/friends
with body

{
  "uuid": "4dbd0673-a113-41eb-8ef3-7533d0f7f622"
}

as default user Herbert yielded a 500: 2001 Database error occurred
Timestamp: 24.03.2023 04:46

Reproducible as another using requesting 691ddae7-c86e-4763-81c2-1b57d8aa7364. Timestamp: 24.03.2023 04:48

[CrsiX]

See #13

[CrsiX]

Requesting new WebSocket message types (maybe as a form of "subtype", but a dedicated type should be fine as well for most of them):

• lobby_invitation self-explanatory, user gets invited to a lobby
• lobby_kick user gets kicked out of his current lobby
• lobby_closed user's current lobby gets closed (may be combined with the previous, but please differentiate those two cases by some flag); the result is the same: the lobby is (temporarily?) inaccessible
• game_finished if a game has been finished for some reason, e.g. victory or resigning (which means: the player may attempt to download the latest game state, but should remove the game from the active list)
• friend_request for new incoming friend requests (same form as FriendRequestResponse?)
• friendship_change if the other user rejected established friendship or dropped a friend request (to update the client's local view)
• account_updated if the user's local account has been changed (e.g. new username)
• account_deleted same as above, may be combined; the WebSocket may be closed after this message, but it's useful to tell a client that his account got removed

_{Use snake_case or CamelCase or whatever you want.}

Of course, all of those are up to discussion and refinement.

[CrsiX]

See #14