# Security-minded design patterns / paradigm for client/server application

I am working on a client/server application and am starting to take it from proof-of-concept to actual implementation. The client is an Android application and the server is in PHP. In similar applications, I'd always simply created a PHP class with appropriate MySQL calls to return JSON objects.

This particular application is a game where clients will end up interacting with each other. My goal is to start with a good basis for security so that I can avoid issues in the future such as duping or other scamming techniques. Obviously, good separation of client and server is one of the keys. Normally I would move to an MVC approach, however it has been suggested that a more RESTful design (e.g., here) would be more secure (or at least a better approach), but I don't really see the benefit other than using a different paradigm.

My question then is twofold. For a client/server application where clients may need to interact/chat/trade, what is a proper paradigm / design pattern to base a server on. Second, is a RESTful design necessary in this case, or is it a programmer's preference?

Edit: I may have had a misunderstanding of REST, and have done some more reading. A more precise question for this community, then, would be what should I build into my API at the outset of development to ensure that I don't run into security issues involving user interactions. For example, say that two users indicate that they wish to trade. My current approach would be for User1 to send the trade request to the server, which then delivers it to User2. Each selects the items to be traded, and that information is passed between each client to the server, which then notifies the opposite client as to the details of the trade. Upon acceptance from each client (either no time limit or a fairly longish time limit...this is not a real-time game), the server then swaps whatever database entries make up the particular inventory selection between the appropriate users.

A second example would simply be a client/server interaction. Assuming that I am limiting client actions to be Attack MonsterA or Defend or Attack MonsterB (in the form of buttons), do I need to consider much from a security perspective other than validating that the client can in fact perform whichever action has been sent?

• Is your question about web service security or how to design your API? MVC and REST are not mutually exclusive; the patterns can be used together, but they have nothing to do with security. I'm confused as to what your actual question is. – Cypher Jul 1 '15 at 1:43
• I suppose its about both. I'm at the point where I am starting to design my API, and I would like to design it with security in mind. MVC to me is a nice clean approach for separating out the various aspects, and I was wondering if the RESTful approach can help with security, or if there is something "better" out there. – the_e Jul 1 '15 at 1:50