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:
Data model differences:
65 createdBy and lastModifiedBy are not available on Hybrid
Unsupported API parameters, parameters that work differently
expand=[true,false] is not working on Hybrid: #85 #87 #114
_optimized is not supported on Hybrid: #105 #111
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
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:
65
createdBy
andlastModifiedBy
are not available on Hybridexpand=[true,false]
is not working on Hybrid: #85 #87 #114_optimized
is not supported on Hybrid: #105 #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