You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I am not sure what are the long term plans for Apigee Hybrid, but as of today, there are known and unknown differences between Apigee APIs on Hybrid and in Public/private cloud. (Is it the right naming convention? 🤔 )
Known differences are described in this document and there are plenty API "families" that are not supported by Hybrid (ex.: Company and Company apps) and there are some unsupported API calls even in the supported ones (ex.: "Get count of API resources" for Developer apps).
Other differences that we have already got bug reports:
This library can hide complexities from developers, like we did with faking CPS support in #43, to make developers' life easier. Although that workaround can be considered a smaller one compared with those differences that we know about Hybrid.
(Clear difference between #43 and the current code in #114 that in #43 we trigger a warning, let developers know that a sub-optimal query is being executed by the library (instead of 1 API call, maybe 10 or more is being sent synchronously), #114 is currently hiding that fact which can lead to unexpected performance regressions on downstream.)
Proposed solution
Instead of adding workarounds to our codebase which was designed and built for public/private cloud, introduce a new Apigee\Edge\Api\Hybrid(or without Edge) or Apigee\Hybrid\Api namespace and start collecting those APIs and data models under this namespace that are supported by Hybrid. Ex.: Apigee\Hybrid\Api\Management\Entity\DeveloperApp
The text was updated successfully, but these errors were encountered:
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
Problem
I am not sure what are the long term plans for Apigee Hybrid, but as of today, there are known and unknown differences between Apigee APIs on Hybrid and in Public/private cloud. (Is it the right naming convention? 🤔 )
Known differences are described in this document and there are plenty API "families" that are not supported by Hybrid (ex.: Company and Company apps) and there are some unsupported API calls even in the supported ones (ex.: "Get count of API resources" for Developer apps).
Other differences that we have already got bug reports:
createdBy
andlastModifiedBy
are not available on Hybridexpand=[true,false]
is not working on Hybrid: [#67] Hybrid compatibility with "expand=false". #85 Hybrid API: Call to environments listing does not support expand=false #87 Apigee hybrid /organizations call does not allow expand=true. #114_optimized
is not supported on Hybrid: Error on Developer App Analytics page for Hybrid Org #105 Hybrid does not support the "_optimized" parameter. #111This library can hide complexities from developers, like we did with faking CPS support in #43, to make developers' life easier. Although that workaround can be considered a smaller one compared with those differences that we know about Hybrid.
(Clear difference between #43 and the current code in #114 that in #43 we trigger a warning, let developers know that a sub-optimal query is being executed by the library (instead of 1 API call, maybe 10 or more is being sent synchronously), #114 is currently hiding that fact which can lead to unexpected performance regressions on downstream.)
Proposed solution
Instead of adding workarounds to our codebase which was designed and built for public/private cloud, introduce a new
Apigee\Edge\Api\Hybrid
(or withoutEdge
) orApigee\Hybrid\Api
namespace and start collecting those APIs and data models under this namespace that are supported by Hybrid. Ex.:Apigee\Hybrid\Api\Management\Entity\DeveloperApp
The text was updated successfully, but these errors were encountered: