I have this little bit simple and general question. Let's say I build an android app which requires an online server to communicate with. The thing is that I want to make the communication on my own ( because now I know only with http post/get). Are there any libraries or how do you do this at all?
If you want to start experimenting with client/server communication with Android and a web service you don't need to develop a fully blown RESTful API to do it (though there are very good reasons why you might want to use a RESTful API eventually when you've had enough experience to think about how to design it well).
The first recommendation is to use HTTPS and not HTTP if you are communicating over a public network (like the Internet for example). Otherwise all data between client and server will be visible to anyone and everyone who can see the data.
For the simplest solution, the client on the Android device could, for example, POST an HTTPS form with some simple fields like 'username' and 'password' (so you can authenticate the client device rather than accept input from anyone poking around at your server's API), and a third field called something like 'content' where you send the info from the client to the server. The sending of the username and password in the form is another reason to use HTTPS - otherwise authentication is pointless.
The form field 'content' could contain any kind of data, including request for data from the server, or data you want to store on the server.
The server then only has to accept HTTPS form posts, and read the username and password and check them, and then process the content and reply with an appropriate response. The response could just be plain text, or JSON or XML, or whatever. The library on Android that performs the HTTPS POST will read this response and pass it to the client system to process.
What you put in the content message, how you process it, and how your client responds to the response is up to you.
RESTful APIs do exactly the same kind of thing, but use the HTTP protocol verbs (PUT, GET, POST, DELETE etc.) to tell the server what you want to do with the data you send to it. You can simulate this in the server's response to the HTTPS form POST even though this is, by many, considered to be bad practice. RESTful APIs make you think about what you are doing with data, and how to think about resources in a more structured way, but they are not mandatory for client/server communications over HTTP.
So I think experimenting with simple form POSTs for all communications until you are satisfied how your system might work, and then rewriting the API part to be RESTful may be a good way to go. It could be that you never go RESTful because the form POSTs are good enough for a simple application.