I have following scenario:
The Android clients communicate with a PHP server via HTTP Post. The PHP server is communicating with mySQL database and sends the output as JSON to the Android client.
Now I am concerned that people sniffing the traffic, find out the URL and will post a lot of grap in my database.
I have no concern of sniffing the payload. So it does not necessarily be encrypted.
I was thinking of TLS/SSL which comes in mind because of the HTTP connection. But I am not sure what is the prefered way to go in this scenario.
What you want to do is employ mutually-authenticated SSL, so that your server will only accept incoming connections from your app and your app will only communicate with your server.
Here's the high-level approach. Create a self-signed server SSL certificate and deploy on your web server. You can use the keytool included with the Android SDK for this purpose. Then create a self-signed client and deploy that within your application in a custom keystore included in your application as a resource (keytool will generate this as well). Configure the server to require client-side SSL authentication and to only accept the client certificate you generated. Configure the client to use that client-side certificate to identify itself and only accept the one server-side certificate you installed on your server for that part of it.
If someone/something other than your app attempts to connect to your server, the SSL connection will not be created, as the server will reject incoming SSL connections that do not present the client certificate that you have included in your app.
A step-by-step for this is a much longer answer than is warranted here. I would suggest doing this in stages as there are resources on the web about how to deal with self-signed SSL certificate in Android, both server and client side. There is also a complete walk-through in my book, Application Security for the Android Platform, published by O'Reilly.
SSL won't help you, as the traffic can be sniffed before the data hits the wire, and people will STILL be able to figure out your API calls and fill the DB with crap.
You can "secure" the service with access tokens and username/password requirements. But again, they won't prevent a malicious user from flooding your system with bad data. However, it would let you track down WHICH user was doing so, as they'd have to be using a unique access token of some sort to get at your system.
