Your question is scattershot and not very clear so this can't be a complete answer
the firstname of the self sign has to be my domain name?
Only for SSL/TLS server -- mostly.
What Java keytool prompts as first and last name is the CommonName attribute in the Subject name (also Issuer name for selfsigned). For SSL/TLS servers it used to be required that CommonName either be the domainname used by client(s) to access the server (since a server can have several domainnames but a given request/URL uses only one) or be a leftmost-only wildcard that matches the domainname used; the latter case is useful if you have several closely related servers like sales.example.com and support.example.com .
Nowadays the SubjectAlternativeName extension (abbreviated SubjectAltName or just SAN) is usually used instead; it can contain multiple entries and several types of entries (not just DNS, but DNS is used for SSL/TLS servers), and if present reliers should use it and ignore CommonName, but not all do so you should still set CommonName. For (Sun/Oracle) Java 7 or later you can use e.g. -ext SAN=DNS:example.com,DNS:www.example.com,DNS:www2.example.com
For certificates (and keys) used for purposes other than SSL/TLS servers, the rules vary. It appears you want a key and certificate to authenticate a client to some REST API; it is not clear if this is in the SSL/TLS (possibly HTTPS) protocol or some other method. Depending on the protocol/method used, the needs of the server (and perhaps middleware the server uses), and the CA or CAs trusted by the server, they might want a domainname or something else.
However, in this case it may not matter what you put in the CSR, because the CA can change it to what they want.
Is the self sign certificate called root certificate?
Not really. A root certificate is actually a kind of CA certificate, specifically one that issues (and is used to verify) other certificates, but is NOT itself issued by a higher-level CA; i.e. in a hierarchy of CAs it is at the top. (Unlike natural trees that have their roots in the ground, computer trees usually have their root -- and usually only one root -- at the top.) A root certificate is selfsigned, but not all selfsigned certs are truly root certs. However, even when a selfsigned cert is not actually a root it may still be handled by some software as a root because that's more convenient. To be clear, if you have a selfsigned cert for an end entity rather than a CA, you should call it selfsigned and not call it (a) root.
I give my CSR to CA(e.g. verisign). In return Versign give me a certificate. Is that called intermediate certificate?
A public CA like Verisign-now-Symantec actually gives you several certificates, but only one of them is really 'yours'. This is because the root CA key (and cert) is much too valuable to be used for routine signing; instead it issues some (usually several) certificates to intermediate CAs, which are then used to issue end-entity certificates. This process may be extended to more than one intermediate level, but rarely if ever more than two.
See Why is it more secure to use intermediate CA certificates? and Do I put my subordinate (intermediate) or root CA certificate in my truststore?
Thus when you submit a CSR and prove your identity/authorization, the CA will issue an end-entity certificate with your identity and key, and provide that certificate. It will also provide copies of the intermediate cert (or certs) to be used with your cert, and possibly a copy of its root cert for completeness.
Depending on the CA (and perhaps your request) it may provide these certs together as a 'bundle' or 'chain', or it may provide them separately.
If you use a CA with significantly smaller scope, such as one run by the server's owner, they may skip the intermediate layer and just give you a cert issued by their root.
Do CA provides private key too? Where do I get the private key?
As already answered, no. You already generated the privatekey; that's what -genkeypair does. It's in your keystore file, and should remain there, protected by an adequately strong password.
Now, there is a REST API server. That server requires certificate to make calls. Me(client) needs to call his REST API, which certificate do I give him before calling the REST API?
When I make request to the REST API server which certificate do I give him now inside a keystore?
First, be clear what this 'certificate' is for. If you are communicating over HTTPS (and thus SSL/TLS) your client needs to validate the server's certificate, and if the server is using a certificate that is not under a wellknown CA (including a selfsigned cert, which is not under any CA), then you need their root or anchor in your truststore. If you are communicating over HTTPS and they want to use SSL/TLS client authentication, you need a certificate AND PRIVATEKEY in your keystore, and that certificate needs to be issued by a CA the server's owner(s)/operator(s) trust, which might or might not include all wellknown CAs and might or might not include a CA they operate themselves. And if they want you to do some security method instead of or in addition to SSL/TLS, it depends what that is. All of these are different things, and might even exist in combination. Without details (or a reference that provides details) your questions are unanswerable.
