I'm pretty new to the game side of things. However, I built up a pretty solid generic server/client framework using c#. When I mean generic, I mean very generic. Basically with a few lines of code you can make a server, where all the meat is done via subscribing to the server events (connections, messages, etc, etc)...

That got me thinking of how I might network a game using this idea. I'm more into the casual environment of things like card games. Specially ccg's/tcg's. These types of games are not physics demanding, but still can be networked so users can play against others.

All messages get converted to a byte array upon being sent over the network, be it from client or from server. So I ventured out and created a little test where the client can send "messages" to the server. Let's say we want to login, it might look like this:

client.Send(new GenericMessage("Login", new object[] { "Email", "password" }));

So we can just have clients send their "actions", where the server will do the validation of said "actions" and either do nothing or perform whatever it needs to do. By this theory, when I think of the ccg/tcg idea, we can make "actions" like "DrawCard", "MoveCard", "PlayCard", "Attack", etc...

Clients can send whatever they want whenever they want, as mentioned the validation would be done server side.

The whole reason for this post though, is when I think about it, it might be a complete waste of time, because the server side isn't running a "game loop". The clients would be, as they could be theoretically programmed in any language.

Is there any reason this is a bad design for a non physics, non realtime demanding game?

RPC mechanisms are plenty -- you can shake a stick at any year between 1985 and 2015 and you'll probably find a dozen new ones each of those years :-)

There's nothing wrong, as such, in that.
More mature solutions will provide things like:
- Session management (how do you know that a new connection belongs to a previously-authenticated user?)
- Type checking (generating functions that check the type of arguments for you, and automatically fail if it's wrong)
- Wrapper library generation (generate "Result SendLogin(String name, String password)" type functions for client & server)
- Proxying, load balancing, and resiliency support (gateways vs app servers, multiple ingress points, etc)

That being said, if you are building a turn-based game, with no real-time simulation on the server, you're much better off using the most ubiquitous transport mechanism in history: HTTPS.
The payload could be JSON or XML, doesn't really matter. (But if you don't choose JSON you're making a mistake! :-)
The "verb" could either be part of the URL, or a field within the payload.
The "make it easy to add a function to do a thing" holds with a thin wrapper around a HTTP client and a HTTP server on either end of the connection.

The benefit of using HTTP(S) is that you get all the fantastic infrastructure that is already there, for anything from clients running on smart watches, to servers with auto-scaling to increased load, and everything in between.

Session checking, type checking, load balancing, etc are good points, but not relegated to only game loop driven servers.

I haven't done any web based programming before, just some knowledge of asp/HTML/JavaScript. If going to an https route won't I need a domain and create the page(s) to do everything?

No you'll need neither, you can connect to the server by IP and you don't need "pages" what you need is some form of web service just handling those requests.

You will need a server no matter what your protocol is. How else will you run your server-side code?

You will need a domain no matter what your server is. How else do the clients figure out how to get to your server?

What HTTP(S) does instead of raw serialization over TCP is give you a well-supported foundation for all the network "glue" that goes inbetween.
Whether you want to take advantage of this or not is entirely up to you. Fast-paced games almost never use it. Turn-based or batch-based operations very often do.

Thank you so much for the explanation!

I do have a domain, a free one for testing, with no-ip and their dynamic client so I can run the "server" on my laptop and have outside clients connect to it.