How to organize the principle of data transfer between the client and the server?

Question

.NET

I am writing a client-server application. I was puzzled by the question of what approach to choose in data transfer between the client and the server. For example, there should be the same user authorization/registration functionality. That is, the server accepts some commands and responds to them.
My options:

1. Use HttpWebRequest/HttpWebResponse
   
2. Use TcpSocketListener/TcpSocketClient
   

First option:
+ higher abstraction (i.e. the last (application) level of the OSI model: it is easier to write code and transfer data (there are headers, body ...)
- I don’t know how to standardize data (so that both the client and the server use the same the same data exchange agreement)
Second option:
- a lower level of abstraction (transport layer of the OSI model): it is not so convenient to write code
+ you can standardize data exchange using a dll file.
That is, as I usually did the agreement between the client and the server:

1. I created MyRequest.dll, which has enum Command (the command that the client requires from the server) and byte[] data (the serialized data that is needed to execute the command) and MyResponse.dll.
   
2. I connected both libraries to both the client and the server.
   
3. I know that the client/server work on the same "standard" written by me.
   

What do you think? Or maybe you should understand SOAP (I didn’t really understand how it works)? Your suggestions will be welcome.

Answer 1

It is worth understanding the RESTful (REST-like) HTTP API as an approach that comes in a larger number of typical tasks, and understanding OpenAPI , and all your problems about the standard and about OSI will be solved. And only later, if you suddenly see that you really need RPC over some Protocol Buffers - then you will do it.
You are now in a vacuum regarding the technologies used for client-server interaction, you need to get out of this vacuum. So much has already been done about the same authorization / registration, and protocols (like OpenID Connect) and frameworks (like support in ASP.NET for all typical scenarios), that there is already plenty to choose from.

Answer 2

tls > http > json > own standard
PS But as part of a course project, in order to simplify the construction in .Net, I would replace json with xml - the standard library already has xml serialization / deserialization mechanisms, but json does not.

Answer 3

It turns out the following order of questions
1. Message (text or binary) (format OR own OR protobuf OR jsonrpc OR xmlrpc OR etc.)
I would recommend jsonrpc 2.0 because it is understandable to people and at least look at it to take the idea as a basis.
2. Transport. If security is not steamed, then https, if steamed, then TCP in ssl. If there is no security, then there is no difference, everything is tcp. If you surprise the teacher, then UDP, but here you yourself with a mustache, you will have to send ACK yourself and according to some principle, you will also have to describe it.