Hi
@vbalan - I don't understand your example about XACMLs. I don't see how that would affect the existing proxy. Surely I'm missing something. If the XACMLs are remote with respect to the proxy, and the URL at which the XACMLs can be retrieved remains the same, then the proxy need not change at all. so anyway, I don't see what XACML updates has to do with anything. Let's put that aside.
As for your prior comment, you wrote:
In my opinion, running the deploy from CLI using the proxy bundle isn't the same as "save as new revision".
I don't know what this means either. But let me put that aside and try to clarify the situation. The way the UI works - when you have the API Proxy editor open, the Apigee UI holds in memory all of the existing API Proxy "stuff" - all of the policies, all of the endpoint definitions (proxy and target), all of the resources, including JS, XSL, Java JARs... When you click "Save as New Revision", the UI posts all of that data back to the Apigee Edge management server.
So if you would like to emulate that via a command-line request, something you could automate, then you need to zip up all the materials for the API Proxy bundle, and invoke the management API that does proxy import . The import looks like this:
CURL -X POST -H "Content-Type: application/octet-stream" \
"${mgmtserver}/v1/o/${orgname}/apis?action=import&name=${proxyname}" \
-T ${bundleZip}
The powershell Export + Import commands that the other responder had suggested... they do exactly this. But of course you do not need powershell to do this; that's just a convenience wrapper around the RESTful API. You can twiddle the API with anything that does HTTP, like curl, or nodejs, or whatever.
LinkedIn
Twitter
