Open echlebek opened 3 years ago
I was the reporter of this bug in Slack.
The above issue doesn't fully summarize the problem. URIPath
is valid when posting to a resource that already exists. The problem is when using client.PostResource
to create a resource, URIPath
is going to generate a non-existent resource path that cannot be used for creates. As a concrete example, consider using PostResource
to generate a new check config. The URL that needs to be POST'd to is something like /api/core/v2/namespaces/<ns>/checks
but because PostResource
is relying on newRequest
which in turn calls on the underlying CheckConfig
's URIPath
, it's going to get a url like /api/core/v2/namespaces/<ns>/checks/<check-name>
which is incorrect.
I wonder if it would be better to expand the API for the client to have resource-specific CRUD operations rather than generic *Resource
actions. At the cost of making the API for the client significantly larger in terms of number of methods, it would allow us to provide a more user-friendly API that handles all the low level resource machinery for you.
Recently, a community user attempted to use the HTTP client, but was unable to, because the client sends POST requests to the incorrect URL.
The issue is that the library uses a URL generated in part by URIPath, which includes the namespace and name of the resource. However, when targeting routes with POST, this results in incorrect paths.
The library should handle these situations gracefully and come up with the correct URL when instructed to use POST.