Are both of these APIs supported for undeploying an API proxy?

[sgilson]

There are two APIs available for undeploying an API proxy. Are they equivalent? Do they both take a "force" query param?

- POST with environment as a query param

/organizations/{o}/apis/{apiproxy}/revisions/{rev}/deployments?action=undeploy&env={e}

- DELETE with environment as part of the URI:

/organizations/{o}/environments/{e}/apis/{apiproxy}/revisions/{rev}/deployments

Stephen

[#2 · Accepted solution]

Hi sgilson , AFAIK both works as expected but env in query name is deprecated where as the new API (env in request path) was brought to support RBAC on APIproxies .

UI uses #2. Even though #1 works fine , it is recommended to move to #2 as new functionality will be added to #2 . Do you see any issues with #2 ?

[sgilson]

Thanks Maruti,

They both work as expected, but I wanted to make sure to use the correct one going forward.

What about the "force" query param? Is that supported by both?

[#4]

@sgilson

I don't remember exactly about force but what ever is supported by #1 will be supported by #2 . I also see that #2 is documented everywhere and we don't see #1 right ?

[adas]

@sgilson As far as I know, the force parameter is only supported in the earlier version of the api. Like @Maruti Chand mentioned, the new api was introduced to support RBAC and let the UI enforce the RBAC for proxy deployments. Going forward, in our documentation we should only refer to the new API, but then there are features like abtest which is only supported in the old api as of now. That's probably the reason why the old api is not been taken out, whereas the new api supports RBAC, seamless deployment etc.

[ozanseymen]

"there are features like abtest which is only supported in the old api as of now"

Are you saying abtest is a supported feature now?

[adas]

@Ozan Seymen Only in the new old deployment api so far. There's a story added to support it in the new deployment api too, but its still not in development.

Sample:

http://${__P(ManagementIp)}:${__P(ManagementPort)}/v1/organizations/{org}/apis/{apiproxy}/revisions/...


http://${__P(ManagementIp)}:${__P(ManagementPort)}/v1/organizations/{org}/apis/{apiproxy}/revisions/...

This would mean revision 1 gets 90% of the traffic while revision 2 only receives 10% of the total traffic sent to this api. I don't think its a publicly documented feature but you can definitely give it a try.

If you want to force the requests to go to a particular revision, you can send the following request header which would override the weight specified above:

X-Apigee.abtest: {revision}

[#8]

Wow, cool! Yeah, I want to learn more about this. In the example below @arghya das, where did you specified 10% and 90% and the revision id? Definitely, many customers would be interested in this. Also, this should be part of the Dev Bootcamp.

I wonder if there are any reports that can be used with this, so, for instance, I want to know the traffic, and rate of errors from one revision API in particular.

Thanks!

[#9]

You may want to check this http://community.apigee.com/questions/2448/gradual-parallel-deployment.html .

abtest works well as mentioned by @arghya das but it is not publicly out yet and there is no documentation around that as I believe the team is working on making some changes to that feature before making it public or part of release notes .

BTW @dzuluaga , we always log the revision number in analytics by default .

[#10]

True. It's part of dimensions. I'm looking forward to trying this one up. In the meantime, if you have any documentation, please email it to me directly. Thanks! This would be great to integrate with Log Management to retrieve more info about the revision and stack traces for root cause analysis.

[ozanseymen]

"but it [abtesting] is not publicly out yet"

Yeah, when we mention and explain it in community site, it IS out!.. publicly... 🙂