Peter has a great write-up about this, so I won’t go into much detail here. Go read his post, then come back for a bit more context.
You have always been able to get a data service to process requests using a specific URI as the root. The data service doesn’t have some magic knowledge about where it’s being hosted; instead, it relies on the IDataServiceHost2 interface for this.
This is a “big hammer” kind of customization, though, because it requires you to completely reimplement the host, including things like header processing, some error handling, and managing request and response payloads.
In the current version, you can keep relying on the built-in support for WCF hosting, and simply use the technique that Peter described to tweak the service for the very common case of wanting to provide the illusion that the service is hosted at a different URI, one that for example includes a session token.
PS: remember the companion MicrosoftDataServicesRequestUri property; again, Peter does a good job explaining how that works.