The key thing to understand is that REST web services usually rely on an Access Key to be created ahead of any such calls. The Access Key would contain a reference to the end user who has logged into REST web services.
The following document, KB000045577, describes how such an Access Key may be generated in REST web services activity.
After a given Access Key is generated, it will be stored into table usp_rest_access. This table stores the access key and the corresponding contact that logged in on the given access key as well as its expiry.
While Service Desk does not natively run any default logging for REST web services, if one examines database activity at the time an Access Key is generated, there will be entries inserted into tables usp_session_ext, session_log, event_log, and usp_rest_access, which all reference the REST web service Access Key.
For example, for table usp_rest_access:
INSERT INTO usp_rest_access ( access_key, contact, expiration_date, last_mod_by, last_mod_dt, secret_key, id ) VALUES ( ? , ? , ? , ? , ? , ? , ? ) Input (<access_key:int>622635826|<contact:uuid>4F89491F9F21EE43A84A6BACF002F2A0|<expiration_date:time>11/08/2018 14:16:54|<last_mod_by:uuid>4F89491F9F21EE43A84A6BACF002F2A0|<last_mod_dt:time>11/01/2018 15:16:54|<secret_key:string>(NULL)|<id:int>400004)
Subsequent rest web services calls will then query the usp_rest_access table for the given access key.
For example, an end user runs a GET on call request data. Before any activity to perform the query on the call request data takes place, Service Desk will query for the Access Key specified in the GET directive on the call request table:
SELECT rest_access.contact FROM usp_rest_access rest_access WHERE rest_access.access_key = 622635826) Input (<None>
In the above two queries, access key 622635826 is the focus of the insert and selection action on table usp_rest_access.
Once the query is completed, and the corresponding contact is retrieved from table usp_rest_access, then the activity to perform GET and POST will proceed.