Answer as below configuration:
on R1
config terminal
ipv6 unicast-routing
inter eth0/1
ip addre 192.168.1.1 255.255.255.240
ipv6 addre 2001:db8:aaaa::1/64
not shut
end
copy running start
on R2
config terminal
ipv6 unicast-routing
inter eth0/1
ip address 192.168.1.14 255.255.255.240
ipv6 address 2001:db8:aaaa::2/64
not shut
end
copy running start
---------------------
for test from R1
ping ipv6 2001:db8:aaaa::1
for test from R2
ping ipv6 2001:db8:aaaa::2

Explanation
Floating static routes are static routes that have an administrative distance greater than the administrative distance (AD) of another static route or dynamic routes. By default a static route has an AD of 1 then floating static route must have the AD greater than 1. Floating static route has a manually configured administrative distance greater than that of the primary route and therefore would not be in the routing table until the primary route fails.

PUT is most-often utilized for **update** capabilities, PUT-ing to a known resource URI with the request body containing the newly-updated representation of the original resource. However, PUT can also be used to create a resource in the case where the resource ID is chosen by the client instead of by the server. In other words, if the PUT is to a URI that contains the value of a non-existent resource ID. Again, the request body contains a resource representation. Many feel this is convoluted and confusing. Consequently, this method of creation should be used sparingly, if at all. Alternatively, use POST to create new resources and provide the client-defined ID in the body representation-presumably to a URI that doesn't include the ID of the resource (see POST below). On successful update, return 200 (or 204 if not returning any content in the body) from a PUT. If using PUT for create, return HTTP status 201 on successful creation. A body in the response is optional-providing one consumes more bandwidth. It is not necessary to return a link via a Location header in the creation case since the client already set the resource ID. PUT is not a safe operation, in that it modifies (or creates) state on the server, but it is idempotent. In other words, if you create or update a resource using PUT and then make that same call again, the resource is still there and still has the same state as it did with the first call. If, for instance, calling PUT on a resource increments a counter within the resource, the call is no longer idempotent. Sometimes that happens and it may be enough to document that the call is not idempotent. However, it's recommended to keep PUT requests idempotent. It is strongly recommended to use POST for non-idempotent requests. Examples:
https://www.restapitutorial.com/lessons/httpmethods.html