I am filling out a Godot user survey, and I'm not sure how to answer this question:
Do you use (or plan to use) networking in your games? *
Yes, for real-time peer-to-peer multiplayer
Yes, for authoritative server (cloud hosted) multiplayer.
Yes, for connecting with a server (REST-style)
No
I don't understand the difference between the middle two options, authoritative server (cloud hosted) multiplayer and connecting with a server (REST-style).
What are these options describing?
Authorative and REST seem like orthogonal concepts from my understanding.
Authoritative Server
Clients become glorified controllers and rendering engines. They send inputs to the server, and ultimately the server sends back information which is correct (or authorative). Basically the server is always right, and is the baseline of truth. Unlike in P2P, where the peers themselves decide truth. You can imagine how this would be useful in multiplayer games to prevent hackers.
REST
REST refers to the API paradigm that is used to interface with the server. REST servers usually communicate via HTTP requests, unlike servers with realtime constraints which create socket connections or send packets directly via UDP. RESTful protocols are stateless, and therefore RESTful messages are often huge as they must include all their state every time they communicate.
Edit
Philipp added that:
Another difference worth mentioning is that in the REST paradigm, all communication is initiated by the clients. The server cannot notify clients that something changed in the game states. The client must actively request that resource and see for itself if it changed. [...] An authoritative server, on the other hand, can message the clients immediately whenever there is a change in the game state they need to know about.
This means that REST could be employed in a turn-based dungeon crawler, as a player initiates the turn, and the server could send a response. While most real-time games could not adapt to the RESTful paradigm, because they rely on the server having being able to tick at set rates and message clients independently of their inputs.
I'd say this is a very poorly phrased survey question, so it's natural to find it confusing.
It looks like it means to ask:
Do you have multiplayer features where a server (possibly but not necessarily cloud hosted) maintains the shared game state and sends updates to all players in that session?
or
Do you communicate with a server for other features, like login authentication, downloading news/updates/special event content, logging to leaderboards, maintaining an online inventory / saved progress, etc?
But I'd argue it's using the wrong wording if that's what it wants to know.
Authoritative is a description of the server's responsibilities. An authoritative server does not just relay client actions to their peers. It takes a role in vetting the client's report and applying only valid changes to the game state/simulation, and communicating that authoritative account to the other clients.
Cloud is a description of where the server is hosted. In contrast to a dedicated server running on a specific machine, a cloud-hosted server is a program uploaded to a service that maintains a fleet of machines, and can spin up one or many instances of your server program across that network on demand.
REST is a description of how communication with the server is structured. I won't repeat the whole definition here since it's covered comprehensively elsewhere.
All 8 possible combinations of these keywords can exist. I've built a cloud-hosted authoritative server that communicates via a REST API, for example. (For an asynchronous game, so peers could pull down the latest authoritative state with a GET request) So I'd say they're not the right terms to use for this question about users' server needs.
I believe that what they mean with an "authoritative server (cloud hosted) multiplayer" is a server holding TCP connections or UDP pseudo-connections with the clients. All the game mechanics run on the server. The clients send messages to tell the server what they want to do. The gameserver calculates the results. Then it sends those results to any clients who need to know about them. Some examples of use-cases for such servers are:
REST stands for Representational State Transfer. It's a paradigm where clients make requests for specific resources to a server (usually via http/https) and the server responds. Clients are both able to transfer new data to the server (POST) or retrieve existing data from the server (GET).
But one central part of the REST paradigm is that all communication is initiated by the clients. Every client request gives the server exactly one opportunity to send them a response. That means the server can not actively inform the clients about something they didn't specifically ask for. This makes the REST paradigm infeasible for real-time games. But there are still a couple use-cases in game development where REST-style protocols can be useful. For example:
