I don't know how their code is written, and I can't see the traffic between a console and their service anyway, so I'm spitballing here.
Typically, you create a web service with an API, which is often (but not always) HTTP-based. In the case of matchmaking, your client would call the web service endpoint, something like: "http://gemsofwar.com/api/find-opponents", and pass in authentication data in the header corresponding to your session token or authorization data. The service would respond with an HTTP response, the payload consisting of offerings, and other metadata for use in client display (relevant here would be team score). Changing the client would not necessarily require changes to the service, though if new features are exposed then the service would need to be augmented to supplement those.
What I don't know is whether the services in use by Console and PC/Mobile are the same. Clearly, the environment (sandbox, or group of players and economy) is different, but there are two possibilities as to how this is accomplished:
- There is a single web service, which is able to provide data for and perform operations on behalf of multiple sandboxes.
- There are separate web services supporting the PC/Mobile clients and the Console clients; potentially even two separate web services for the two consoles.
If it were me, and I were developing all clients from the ground up, you can bet I'd invest once in one web service and make it smart about respecting sandbox (1). But in the case of Gems of War, the Console version was developed by a separate team from the PC/Mobile one, and could quite conceivably have a completely separate service supporting it (2).
If (2) is the case, then the development team has a decision to make at the point of the Unity switchover: do we also move to the Console service, and migrate the user data to that service, or do we stick with what we've got and maintain the existing API? My money is on them not juggling too many balls at once, and changing over the client only in this instance.