fix(client): resolve REST endpoint from discovery profile#90
Conversation
|
Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA). View this failed invocation of the CLA check for more information. For the most up to date status, view the checks section at the bottom of the pull request. |
ynachiket
force-pushed
the
fix/endpoint-resolution-from-discovery
branch
2 times, most recently
from
528ebe7 to
8e983bf
Compare
The happy path client was ignoring the `endpoint` field from the `/.well-known/ucp` discovery response and instead hardcoding all API paths against the initial `--server_url`. Per the UCP spec (Endpoint Resolution section): > "The endpoint field provides the base URL for API calls. OpenAPI > paths are appended to this endpoint to form the complete URL." This works by coincidence when the merchant serves the API at its domain root (e.g. `http://localhost:8182`), but breaks when the merchant mounts the API under a path prefix (e.g. `https://merchant.com/buy/v1`). In that case the client would hit `https://merchant.com/checkout-sessions` instead of the correct `https://merchant.com/buy/v1/checkout-sessions`, resulting in 403/404. This commit: - Adds endpoint_resolution.py with the resolve_rest_endpoint() helper - Uses the resolved endpoint to recreate the httpx client base_url - Updates exported curl URLs to reflect the resolved endpoint - Falls back to --server_url if no endpoint is found in discovery - Adds 9 unit tests covering path-prefixed, root-level, multi-transport, and missing/empty endpoint scenarios Made-with: Cursor
ynachiket
force-pushed
the
fix/endpoint-resolution-from-discovery
branch
from
8e983bf to
24ca504
Compare
damaz91
added
status:needs-triage
| args.export_requests_to, | ||
| "PUT", | ||
| f"{args.server_url}{url}", | ||
| f"{api_base_url}{url}", |
There was a problem hiding this comment.
If api_base_url happens to have a trailing slash, this can result in double slashes in the logged curl command (e.g., https://example.com/api/v1//checkout-sessions), even though httpx resolves it correctly internally.
A minor improvement would be to use str(response.url) to get the actual resolved URL from the response object, instead of passing the constructed URL string.
|
Thanks for this fix @ynachiket! Just added a minor comment, once addressed we can merge this. Please also resolve existing conflicts (I was doing quite some refactoring these days) |
damaz91
added
status:under-review
and removed
status:needs-triage
2 participants
The happy path client was ignoring the
endpointfield from the/.well-known/ucpdiscovery response and instead hardcoding all API paths against the initial--server_url.Per the UCP spec (Endpoint Resolution section):
This works by coincidence when the merchant serves the API at its domain root (e.g.
http://localhost:8182), but breaks when the merchant mounts the API under a path prefix (e.g.https://merchant.com/buy/v1). In that case the client would hithttps://merchant.com/checkout-sessionsinstead of the correcthttps://merchant.com/buy/v1/checkout-sessions, resulting in 403/404.This commit: