I guess there are more than one way to do it.. but one solution which works pretty good is using a token-based authentication.

The way it works is that once you do your request with username/password to the server you will need to generate access-token which is returned as a response on successful login. After that, you will place this access-token to be part of your subsequent requests to the protected server-side routes which in turn needs to check the access-token validity each time. This check is typically done as a filter or "before_action" as they call it in the Ruby On Rails world.

Nevertheless, the type of token you generate and how you store it varies as well. I've seen implementations in which tokens are saved to database table and the tokens itself are just a random combination of numbers/letters etc. without any real knowledge in it. For this, you most likely need a database table such as "sessions" which has fields like "access_token, user_id, expires_at".. and after that, you can use "expires_at" field to dictate how long the token is valid. And implement things like "refreshing" token duration and even revoking access.. the user_id here is useful, as like with cookie-based authentication, you often need to know the session user at the server.

Here is more explanation about this approach: http://stackoverflow.com/questions/1592534/what-is-token-based-authentication

However, how I would actually do it (today) would be using json web-tokens because they doesn't require reading/writing to database at all. Instead, the secret used to generate the token is stored to server-side and the token itself carry the information of expires_at and a like. You can even place your user_id and other (less critical) information there. You can read more about it here: https://jwt.io/

And finally, you should treat tokens as passwords. Meaning, send them over https connection.

This is no different from logging in to a website. On a website, you get a session cookie, which typically is something like "userid:expirytime:unique-id:hmac(userid,expirytime,unique-id,key)."

You can issue a similar session token to the users of your REST API. In fact, because you already use HTTP, you can still use cookies. (For UDP based connections, you'll need to manage this cookie at your own protocol layer.)

It's important that you do verify the cookie hmac, and that you do verify the timeout/expiry time. You will also want to issue a new session token when the expiry time gets close, if you want the user to keep the session alive.

Another option is to use OAuth for your API calls. However, as maunovaha suggests, implementations of that typically require looking up the token in some database. You could make that database be memcached or Redis, to make it fast, but it's still slower than "verify the hash."

Sure, you can develop without https connection, but if you don't have any other environment (like staging) between your development <--> production, then you might encounter bugs as you suddenly switch using https and some of those web request/asset urls are not properly set to use https. So I would at least test that https setup locally, before just activating it for the production. Nevertheless, I still suggest that you should prefer using json web tokens over making your own system as it is less hassle and they have library for Java as well. But the choice is yours ofc.