Good morning, I'm in the process of moving from Rancher 2.4.17 to 2.6.6 and it looks like there are some significant changes in how we update a workload from the REST API. Before, we would use this - curl -s -k -X PUT -H "Accept: application/json" -H "Authorization: Bearer $TOKEN” -H "Content-Type: application/json" https://${RANCHER_URL}/v3/project/${CLUSTERID}:${PROJECTID}/workloads/deployment:${NAMESPACE}:${DEPLOYMENT_NAME} -d "@deployment.json" Now it seems we need to use something like this: curl -s -k -X PUT -H "Accept: application/json" -H "Authorization: Bearer $TOKEN" -H "Content-Type: application/json" https://$(RANCHER_URL)/k8s/clusters/${CLUSTERID}/v1/apps.deployments/${NAMESPACE}/${DEPLOYMENT_NAME} -d "@deployment.json" Is that the recommended endpoint for doing a deployment update? Also, I noticed a couple more things I'd like to confirm. #1. That the json body now has to start with {"apiVersion":"apps/v1", "kind":"Deployment"} and #2. We now have to include "resourceVersion":"XXXXXXXXXXX" of the most recent deployment as part of the PUT update? I'd like to minimize the amount of new things we need to add to the deployment JSON so if I can avoid having to do the extra step of pulling in the most recent resourceVersion from the existing deployment, I'd rather not. Or maybe the expectation is that we delete the workload and POST it brand new? Are there any good articles that talk about the REST API changes between Rancher versions and how it relates to things like resource updates? Thanks!

I've heard Rancher folks seem to suggest that there is a lot about the Rancher API that's not necessarily considered stable/public and you can backsolve from the UI but it's not too guaranteed not to change. There has also been suggestions that with 2.6 they're moving to put everything so it can be accessed/done via the Kubernetes API, so that might be a more future-proofed direction to look?

It may be future proof to make your workflow run against kubernetes api instead of rancher api