HTTP Client POST not working as intended

[echlebek]

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.

[SegFaultAX]

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.