That depends on what kind of client this is, and what kind of server. For HTTP the model is one client -> one request -> server -> one response -> to the same client; clients are free to send several requests in parallel (or in a row) to the same server, or to send several requests to different servers.
I'm not sure if this helps, but then, I didn't really understand what you were asking by "what is the right way...", or what you mean by "traditional way".
Let's say i would like to build a group chat.
if one of the clients is posting a message (client send a http request to the server)
now the server has to send the response/request back but to all other clients (to all group members).
the question is in the server-side how can the server response to some clients by getting only one response from one client.
or maybe using a http protocol or server is not recomended in this application?
There are two options: One is to have each of the clients poll for responses. That would mean that every second (for example) the client would send a message saying essentially "Got anything for me?" This can readily be done with HTTP as the protocol. It may not be scalable to thousands of clients, but then I can't really envisage a chat involving thousands of people either.
The other is for each of the clients to run a local server waiting for requests, and then the main server would send its "response" to each of the local servers. This conceivably could be done with HTTP as the protocol, but then the clients couldn't run in a browser. They would have to be standalone applications to be able to run an HTTP server. Also, it could only run on a single network, i.e. a LAN.
So if you're just doing this for programming practice, I would go with the first option. And if you're doing it for a real-life project to be used in production, I would go with the option which involved installing software already written by somebody else.