Problem with session in REST service (bug?)

Problem with session in REST service (bug?)

I made a REST service with the new "Expose REST API" functionality to be used from Android client.
Now when I make a call to it - I see that Session.UserId = 0. I have checked in debug that cookie "ASP.NET_SessionId" has some value.
Then I created empty page to check with it, and just replaced URL of the call to that page, so that instead of "/WebService/rest/Api/Save" it became "/WebService/Save.aspx". Now in that page, Session.UserId has correct value (and "ASP.NET_SessionId" also has some value). So it must be an issue of the new REST functionality.
Why would a webservice have a session.userid?
The webservice doesn't know if the next call is from the same "user"

Thus if you want to keep "track" of the user, you have to create a token that identifies the user and that token is passed in every call. (google for JWTToken for example)

Well, HTTP in general does not know if the call if from the same user, that's why SessionId is sent with every request to identify him.
What I need is to make a REST call as authenticated user. This was working when I was using previous version REST "emulation" via web screens, but is not working any more with a new approach.
Off course I can make my own mechanism of returning login identifier and then sending it in the request body, but this will be just manual re-invention of already existing and built-in SessionId mechanism.

By the way, OutSystemsNow client uses REST to login and then executes following REST requests and loads web application as the same user (session). In particular, "applications" methods of OutSystemsNowService uses Session.UserId. This will be broken too in case if you migrate those methods to a new approach.

I have read a bit and it seems that session in REST is "ideologically" incorrect. Maybe it's not supported by the underlying framework that OS uses. Okay than.
Hi Igor,

Session information is not stored for web services (SOAP or REST), so you'll have to manage that yourself. Since web services are stateless, any state you want you'll have to manage yourself. You seem to be a bit bitter about this, but that's really just common practice. You could always add an Idea to have it an optional platform feature, of course.