Using iControl-REST API

All HTTP URLs presented either as self link or Reference are not pointing to the hostname the request was made to but "localhost", which means before using them one needs to manually replace the host?

The selfLinks and References are pointing back to the iControl REST interface, not to any VIP-specific property. These are references for (directly) accessing sub-components of the virtual (profiles and policies).

The destination field contains the human readable protocol name for well known ports "destination": "10.67.76.30:https" instead of "destination": "10.67.76.30:443", which imho is questionable in an api, since one has to parse content which should already be machine readable.

This mapping comes from /etc/services. You should be able to change this behavior with the following TMSH command:

tmsh modify sys db bigpipe.displayservicenames value true

References to objects in the current partition, like pool in my example, are referenced witchout the path while objects in the common partition are referenced as /Common/object except when the current partion is /Common which seems a little inconsistent?

I don't know that this is true:

curl -k -u admin:admin -X GET https://x.x.x.x/mgmt/tm/ltm/virtual?\$filter=partition%20eq%20test

When passing the partiton as ?$partition=/name the api request returns the correct partition but when using the proper URL-Encoded string ?%24partition%3D%2Fname%0A the parameter is ignored and objects are always returned from the Common partition, which breaks a lot of rest api frameworks, since they tend to properly encode urls before passing them on to the HTTP handler?

See above syntax.

With all profiles having the "kind": "tm:ltm:virtual:profiles:profilesstate" which means the answer does not contain any way to figure out which profile type it actually is, for example from this information it would not be possible to see if it is a ssl-client or a tcp profile, should this not give a list of profiles with refrerences to the actual profiles object ?

Absolutely agree here. You would need to infer the object type from its name (assuming you used a standard naming convention for objects).