GithubHelp home page GithubHelp logo

apigee / apigee-client-php Goto Github PK

View Code? Open in Web Editor NEW
27.0 18.0 30.0 1.62 MB

Client library to make API calls to Apigee Edge Management API

License: Apache License 2.0

PHP 100.00%
rest api php-library composer

apigee-client-php's Introduction

Apigee Edge Client Library for PHP

Build Status Code Coverage Latest Stable Version Total Downloads Minimum PHP Version License

The Apigee API Client Library for PHP makes it easy to develop PHP clients that call the Apigee Edge/ X Management API. The Apigee API Client Library for PHP enables you to interact with the API using objects instead of coding to handle the HTTP request and response calls directly.

Specifically, the Apigee API Client Library for PHP provides access to Apigee Edge and Apigee Management APIs in the following categories:

Apigee Edge

Apigee

For more information about the Apigee Edge and Apigee Management APIs, see Getting started with the Apigee Edge Management APIs and Getting started with the Apigee Management APIs in the Apigee documentation.

The Apigee API Client Library for PHP, built using the HTTPlug library, provides an HTTP client implementation-independent library. You choose the client that best fits your project requirements.

If you need PHP < 7.1 or Monetization API support please install the older edge-php-sdk version. We are planning to add Monetization API support to this library in the near future.

Edge for Private Cloud

Core Persistent Services (CPS) is not available on Private Cloud installations. The PHP API client supports pagination on listing API endpoints (ex.: List Developers). If CPS is not available the PHP API client simulates the pagination feature and it triggers an E_USER_NOTICE level error to let developers know that the paginated result is generated by PHP and not the Management API server. This notice can be suppressed in multiple ways. You can suppress it by changing PHP's error_reporting configuration to suppress all E_NOTICE level errors with changing its value to E_ALL | ~E_NOTICE for example. You can also suppress only the notice generated by the PHP API client by setting the APIGEE_EDGE_PHP_CLIENT_SUPPRESS_CPS_SIMULATION_NOTICE environment variable value to a falsy value, for example: APIGEE_EDGE_PHP_CLIENT_SUPPRESS_CPS_SIMULATION_NOTICE=1.

Support for Apigee hybrid orgs: GA Release

Support for Apigee hybrid API has been added to this library and is now considered to be production ready. If you run into any problems, add an issue to our GitHub issue queue.

Installing the client library

You must install an HTTP client or adapter before you install the Apigee API Client Library for PHP. For a complete list of available clients and adapters, see Clients & Adapters in the PHP-HTTP documentation.

To install the client library using Guzzle 6, enter the following commands:

$ composer require php-http/guzzle6-adapter:^1.1.1
$ composer require apigee/apigee-client-php

Usage examples

Basic API usage

<?php

use Apigee\Edge\Api\Management\Controller\DeveloperController;
use Apigee\Edge\Api\Management\Entity\Developer;
use Apigee\Edge\Exception\ApiException;
use Apigee\Edge\Exception\ClientErrorException;
use Apigee\Edge\Exception\ServerErrorException;
use Apigee\Edge\Client;
use Http\Message\Authentication\BasicAuth;

include_once 'vendor/autoload.php';

$username = '[email protected]';
$password = 'my-secure-password';
$organization = 'my-organization';

$auth = new BasicAuth($username, $password);
// Initialize a client and use basic authentication for all API calls.
$client = new Client($auth);

// Initialize a controller for making API calls, for example a developer controller to working with developer entities.
$ec = new DeveloperController($organization, $client);

try {
    /** @var \Apigee\Edge\Api\Management\Entity\Developer $entity */
    $entity = $ec->load('[email protected]');
    $entity->setEmail('[email protected]');
    $ec->update($entity);
    // Some setters on entities are intentionally marked as @internal because the underlying entity properties can not
    // be changed on the entity level. Those must be modified by using dedicated API calls.
    // So instead of this:
    $entity->setStatus(Developer::STATUS_INACTIVE);
    // You should use this:
    $ec->setStatus($entity->id(), Developer::STATUS_INACTIVE);
} catch (ClientErrorException $e) {
    // HTTP code >= 400 and < 500. Ex.: 401 Unauthorised.
    if ($e->getEdgeErrorCode()) {
        print $e->getEdgeErrorCode();
    } else {
        print $e;
    }
} catch (ServerErrorException $e) {
    // HTTP code >= 500 and < 600. Ex.: 500 Server error.
} catch (ApiException $e) {
    // Anything else, because this is the parent class of all the above.
}

Advanced examples

Unit Tests

Setup the test suite using Composer if it has not already done:

$ composer install --dev

Run it using PHPUnit:

$ composer test

Testing of new changes does not require Apigee Edge connection. By default, unit tests are using the content of the offline-test-data folder to make testing quicker and easier. If you would like to run units tests with a real Apigee Edge instance you have to specify the following environment variables (without brackets):

APIGEE_EDGE_PHP_CLIENT_API_CLIENT=\Apigee\Edge\Tests\Test\Client
APIGEE_EDGE_PHP_CLIENT_HTTP_CLIENT=\Http\Adapter\Guzzle6\Client
APIGEE_EDGE_PHP_CLIENT_BASIC_AUTH_USER=[[email protected]]
APIGEE_EDGE_PHP_CLIENT_BASIC_AUTH_PASSWORD=[PASSWORD]
APIGEE_EDGE_PHP_CLIENT_ORGANIZATION=[ORGANIZATION]
APIGEE_EDGE_PHP_CLIENT_ENVIRONMENT=[ENVIRONMENT]
# If test organization does not support CPS.
APIGEE_EDGE_PHP_CLIENT_SUPPRESS_CPS_SIMULATION_NOTICE=1

There are multiple ways to set these environment variables, but probably the easiest is creating a copy from the phpunit.xml.dist file as phpunit.xml and uncomment the env elements inside the element.

It is also possible to create and use your own data set. If you would like to use your own offline test data set then you just need to define the APIGEE_EDGE_PHP_CLIENT_OFFLINE_TEST_DATA_FOLDER environment variable set its value to the parent folder of your own test data set.

PS.: Some unit tests cannot be executed when the offline test data set is in use, those are automatically marked as skipped.

Our Backward Compatibility (BC) Promise

This library follows the Semantic Versioning strategy. It means only major releases (such as 3.0, 4.0 etc.) are allowed to break backward compatibility and we do our best to keep it this way. The PHP API Client has to be compatible with the latest versions of the supported Apigee Edge APIs. As you can see, almost every class implements at least one interface in this library, therefore, we would like to suggest to rely on interface definitions instead of concrete classes if you build something on the top of this library. Also, prefer encapsulation over inheritance if you extend our classes. We will release a new major version from this library if a change in a supported Apigee Edge API cannot be implemented in the PHP API client without changing an interface.

Support

This project, which connects Drupal 8 with Apigee Edge, is supported by Google. Use our project's issue queue to report any questions, issues, or feedback.

Contributions

We would love to accept contributions to this project, please see the contribution guidelines for this project for more details.

apigee-client-php's People

Contributors

arlina-espinoza avatar cnovak avatar divya-intelli avatar giteshk avatar jaesin avatar kedarkhaire avatar mxr576 avatar phdhiren avatar raakesh-blokhra avatar shadcn avatar shishir-intelli avatar tamasd avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

apigee-client-php's Issues

Support Async API calls

Support Async API calls for loading/deleting/updating multiple entities (developers, apps, api products, etc.) from Apigee Edge much quicker.

The `keepOriginalStartDate` attribute is not always set on rate plan revisions.

Q A
Bug? yes
New Feature? no
Version 2.0.1

Actual Behavior

Serializing a rate plan revision without keepOriginalStartDate set causes an error.

Property "keepOriginalStartDate" has not been initialized on instance of Apigee\Edge\Api\Monetization\Entity\StandardRatePlanRevision class. Expected type: "boolean".

Expected Behavior

Serializing a pate plan what was retrieved from the API via the client should not error.

Steps to Reproduce the behavior

  • First, a rate plan revision that doesn't have the keepOriginalStartDate attribute set to true or false.
  • Load the rate plan revision.
  • Try to serialize the revision.

Subscribe to a rate plan A, cancel it and then subscribe to a plan A again you should get the error.

Proposed Solution

Only return true if keepOriginalStartDate is explicitly set to TRUE.

Change ClientInterface::DEFAULT_ENDPOINT for PUBLIC_CLOUD_ENDPOINT

Changing ClientInterface::DEFAULT_ENDPOINT for ClientInterface::PUBLIC_CLOUD_ENDPOINT should make things more clear since there isn't a default endpoint anymore.
This would involve deprecating ClientInterface::DEFAULT_ENDPOINT in favor of the new ClientInterface::PUBLIC_CLOUD_ENDPOINT.

Missing attributes parameter in AppCredentialControllerInterface::create()

Description

The related API endpoint allows attributes to be set specified for newly created app credentials, but the current implementation in the API client hides this capability in \Apigee\Edge\Api\Management\Controller\AppCredentialController::create().

Steps to Reproduce

image

Notes

  • interface change! See my notes in a similar issue: #116

Version Info

2.0.6

Consider handling Hybrid as an entirely new API

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:

  1. Data model differences:
  • #65 createdBy and lastModifiedBy are not available on Hybrid
  1. 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

Actualize copyright headers

Moved conversation from an active PR: #71 (comment)

@cnovak please share your thoughts about it. I would not drop the license header plugin unless it is actually a legal requirement having different copyright headers on older files.

OAuth Patch for Apigee Edge Client Library for PHP not getting applied

Q A
Bug? yes
New Feature? no
Version 1.0.0-alpha4

Summary

The OAuth Patch for Apigee Edge Client Library for PHP is not getting installed when we run composer.

Steps to Reproduce the behavior

  1. Have a Drupal 8 site running with the apigee_edge module 1.0.0-alpha4 running. Noticed that the patch for OAuth is not installed as the Apigee Client for PHP says it should be if using composer patches.
  2. Ran composer update apigee/apigee-client-php, but the patch was not installed.
  3. Ran composer update drupal/apigee_edge, but the patch was not installed.
  4. Ran composer remove drupal/apigee_edge and then composer require drupal/apigee_edge and the patch was not installed.

What are the steps to get the patch installed on a currently running system? If I reinstall a brand new site, will the patch get applied?

Change ClientInterface constant names and HybridOauth2 class to fit new Apigee naming

The Apigee product used to be hosted at apigee.com. The newer platform of Apigee is now at apigee.google.com and uses Google Cloud. The actual names of these platforms have been changed to:

  • apigee.com: Apigee Edge
  • apigee.google.com: Apigee on Google Cloud

Hybrid is the name for a specific flavor of Apigee on Google Cloud where the Apigee runtime is hosted in a different location than Google Cloud. However, the Apigee API and admin features are still at apigee.google.com.

Since we did not understand the naming when we created the feature, the constant ClientInterface::HYBRID_ENDPOINT is not correct. In the ClientInteface, the constants should be renamed:

  • ClientInterface::DEFAULT_ENDPOINT should be EDGE_ENDPOINT
  • ClientInterface::HYBRID_ENDPOINT should be APIGEE_ON_GCP_ENDPOINT

To avoid breaking changes, the original constants should be marked as deprecated, and the new constants added until we can remove them in a 3.x version. Add comments to explain this info above.

The class HybridOauth2 class is also named incorrectly, and should be deprecated in favor of a class named ApigeeOnGcpOauth2

Add a copyright validation to the code style tools

Because we need to keep the copyright year of a file pinned, and don't change it if the file is edited/moved/copied, we had to remove the header_comment fixer from the PHP-CS-Fixer rules (see #79 (comment)).

It would be good to have a code fixer/sniff that adds this back in a way that we it adds a copyright header with the current year to new files, and ensures the header exists on other files, or at least verifies that all files have a copyright header.

Related: PHP-CS-Fixer/PHP-CS-Fixer#4625

Adding integration testing for Hybrid

Adding integration testing for Hybrid by testing nightly against a hybrid org to validate API calls are not changing.

Prereq: Need an org to test against.

Upgrade PHP version for Travis-Ci to PHP 7.3+

Description

Travis-Ci is using PHP 7.1 currently which is causing the tests to fail since it not familiar with the syntax changes of higher PHP versions.

Steps to Reproduce

Create a new branch from fork and run Travis-Ci tests

Actual Behavior

Tests are failing (syntax errors)

Expected Behavior

Tests should pass since no changes have been made to the branch

Notes

Add any other context about the problem here.

Version Info

travis-ci.com (recommended newer version of travis-ci.org)

Hybrid API: Call to environments listing does not support expand=false

On the Hybrid API: Making a call to /organizations/***organization***/environments?expand=false
fails with error 400. It says the parameter "expand" isn't supported for this resource.
Full response:

TTP/1.1 400 Bad Request
Vary: X-Origin, Referer, Origin,Accept-Encoding
Content-Type: application/json; charset=UTF-8
Date: Fri, 08 Nov 2019 20:12:52 GMT
Server: ESF
Cache-Control: private
X-XSS-Protection: 0
X-Frame-Options: SAMEORIGIN
X-Content-Type-Options: nosniff
Alt-Svc: quic=":443"; ma=2592000; v="46,43",h3-Q050=":443"; ma=2592000,h3-Q049=":443"; ma=2592000,h3-Q048=":443"; ma=2592000,h3-Q046=":443"; ma=2592000,h3-Q043=":443"; ma=2592000
Accept-Ranges: none
Transfer-Encoding: chunked

{
  "error": {
    "code": 400,
    "message": "Invalid JSON payload received. Unknown name \"expand\": Cannot bind query parameter. Field 'expand' could not be found in request message.",
    "status": "INVALID_ARGUMENT",
    "details": [
      {
        "@type": "type.googleapis.com/google.rpc.BadRequest",
        "fieldViolations": [
          {
            "description": "Invalid JSON payload received. Unknown name \"expand\": Cannot bind query parameter. Field 'expand' could not be found in request message."
          }
        ]
      }
    ]
  }
}

Error on Developer App Analytics page for Hybrid Org

Description

After creating a App, On Analytics page I am seeing below error:-
"Unable to retrieve analytics data. Please try again."

On checking Drupal logs I saw below error message:-
"Apigee\Edge\Exception\ClientErrorException: INVALID_ARGUMENT: Invalid JSON payload received. Unknown name "_optimized": Cannot bind query parameter. Field 'optimized' could not be found in request message. in Apigee\Edge\HttpClient\Plugin\ResponseHandlerPlugin->decodeResponse() (line 104 of G:\Projects\apigee_kickstart\vendor\apigee\apigee-client-php\src\HttpClient\Plugin\ResponseHandlerPlugin.php)."

Refer screenshot for Apigee Debug message of Request and Response

Version Info

2.0.5

image
image

Unsubscribe from a rate plan does not work with developerId, only email

Q A
Bug? yes
New Feature? no
Version 2.0.0

Actual Behavior

When trying to unsubscribe from an existing rate plan I get this:
URL id qualifier [[email protected]] does not match with the entity id [someID-0839-4057-84fc-...] or some of these entities may not exist

Expected Behavior

Successfully unsubscribe form a rate plan.

Steps to Reproduce the behavior

The code for the subscribe/unsubscribe is in my fork. I am trying to create a patch that would temporarily solve this issue or give some ideas on how this issue could be better handled in the library.

Proposed Solution

Looks like Apigee\Edge\Api\Monetization\Normalizer\EntityNormalizer::normalize needs a special treatment for the developer ID when calling unsubscribe method. While developer entity ID is used for the subscribe to rate plan is used the unsubscribe requires actual email address as a Developer ID.

Add support for loading non-monetized API products

Is your feature request related to a problem? Please describe.
Describe the solution you'd like

Add support for loading the list of non-monetized API products from Apigee.

There is a note here that only monetized API products can be loaded from Apigee, although there is OOTB support on the API level for retrieving non-monetized ones via the monetized=false query parameter.

See: https://apidocs.apigee.com/docs/monetization/1/routes/mint/organizations/%7Borg_name%7D/products/get

Describe alternatives you've considered

Additional context

Add support for listing app ids that are consuming an API product

Is your feature request related to a problem? Please describe.
There is an (undocumented) query parameter that you can pass to the API products API for gettings the list of apps that are consuming an API product. Combining that with #117 we could have a powerful tool. (This API is also used by the Apigee MGMT API.)

The endpoint is: https://apigee.com/organizations/[ORGNAME]/apiproducts/[PRODUCT_NAME]?query=list&entity=apps

Response:

[ "APP_UUID1", "APP_UUID2" ]

Describe the solution you'd like

Describe alternatives you've considered

Additional context

Error while purchasing plan on PHP 7.3 (Apigee X)

Description

In PHP version 7.3, Error while purchasing a Rateplan in Apigee X (5g org).

Steps to Reproduce

  1. Click on BuyApi menu
  2. From the Rateplan list, click on any plan.
  3. In Rateplan detail page try to purchase a plan.

Actual Behavior

"Neither the property "published" nor one of the methods "getPublished()", "published()", "isPublished()", "hasPublished()", "__get()" exist and have public access in class "Apigee\Edge\Api\ApigeeX\Entity\StandardRatePlan"."

Expected Behavior

Purchase a rate plan successfully.

Screenshots

Screenshot 2021-05-27 11 38 21 AM

Version Info

Drupal 8/9
PHP 7.3

PHP 8 readiness

Is your feature request related to a problem? Please describe.
PHP 8 has been officially released for more then 5 months. It was discussed earlier in multiple threads to have readiness for PHP 8, which is way forward.

apigee/devportal-kickstart-project-composer#39
#121
#127

Describe the solution you'd like

  • Higher and lower version testing
  • Resolve the code if it is not compatible with PHP 8.
  • Need to update multiple dependent module due to this activity and resolve the code standard accordingly.

DeveloperController::getDeveloperByApp() is incorrectly implemented

Description

According to the official documentation \Apigee\Edge\Api\Management\Controller\DeveloperController::getDeveloperByApp() is incorrectly implemented because the related API endpoint returns an array of developer objects instead of one developer object.

To get the developers associated with a specific app, specify the name of the app using the app query parameter.

Notes

Since fixing this requires a change in the related interface we have to be careful about how we introduce this fix. Probably we should do the following:

  • keep the interface unchanged
  • trigger a warning in the default implementation of DeveloperController::getDeveloperByApp() to let downstream devs know that the method works incorrectly, they should use the new method that we introduce in the next step.
  • introduce a new getDevelopersByAppName() in the DeveloperController with a todo that this method should be added to the DeveloperControllerInterface in 3.0.0.
  • leave a todo on DeveloperController::getDeveloperByApp() and DeveloperControllerInterface::getDeveloperByApp() to get them removed in 3.0.0.

Version Info

2.0.6

Error updating `CompanyAcceptedRatePlan` entity.

Q A
Bug? yes
New Feature? no
Version 2.0.1

Actual Behavior

\Apigee\Edge\Api\Monetization\Controller\AcceptedRatePlanController::updateSubscription fails with the following error:

{
  "code" : "mint.resourceIdMismatch",
  "message" : "URL id qualifier [674cdd50-140d-459e-8b95-xxxxxxxxxxxx] does not match with the entity id [company-x] or some of these entites may not exist",
  "contexts" : [ ]
}

The posted payload is as follows:

{
  "created": "2018-10-03 19:53:04",
  "developer": {
    "id": "company-x"
  },
  "endDate": "2019-02-07 17:01:15",
  "id": "674cdd50-140d-459e-8b95-xxxxxxxxxxxx",
  "prevRecurringFeeDate": "2018-10-04 00:00:00",
  "ratePlan": {
    "id": "foo_plan"
  },
  "renewalDate": "2019-10-04 00:00:00",
  "startDate": "2018-10-04 00:00:00",
  "updated": "2018-12-12 00:00:58"
}

Expected Behavior

The payload should be using "company" instead of "developer" like the following.

{
  "created": "2018-10-03 19:53:04",
  "company": {
    "id": "company-x"
  },
  "endDate": "2019-02-07 17:01:15",
  "id": "674cdd50-140d-459e-8b95-xxxxxxxxxxxx",
  "prevRecurringFeeDate": "2018-10-04 00:00:00",
  "ratePlan": {
    "id": "foo_plan"
  },
  "renewalDate": "2019-10-04 00:00:00",
  "startDate": "2018-10-04 00:00:00",
  "updated": "2018-12-12 00:00:58"
}

Steps to Reproduce the behavior

  • Load a company accepted rate plan.
  • Try to update the rate plan.

Proposed Solution

  • Correct the legal entity key.
  • Add a test to verify the payload.

getConsumerKey() getConsumerKey()

Q A
Bug? no
New Feature? no
Version N/A
I am very sorry that I have got a noob question. I spent a few days trying to get an app key with getConsumerKey() but have no luck so far.

Actual Behavior

What is the actual behavior?
N/A

Expected Behavior

What is the behavior you expect?
getConsumerKey() gets key from my app.

Steps to Reproduce the behavior

What are the steps to reproduce this bug? Please add code examples,
screenshots or links to GitHub repositories that can demonstrate the problem.
..
// Create a new developer.
$dc = new DeveloperController($clientFactory->getOrganization(), $clientFactory->getClient());
$developer = new Developer(['email' => $developerEmail]);
$developer->setUserName($username);
$developer->setFirstName($fname);
$developer->setLastName($lname);
$developer->setAttributes(new AttributesProperty(['CONSUMER_TYPE' => 'PMS_VENDOR']));
$dc->create($developer);

// Create a new developer app. - works fine
$dac = new DeveloperAppController($clientFactory->getOrganization(), $developerEmail, $clientFactory->getClient());
$developerApp = new DeveloperApp(['name' => $appName]);
$developerApp->setDisplayName($appName);
$dac->create($developerApp);

// get consumer key. - does not work
$appId = $developerApp->getAppid();
$appCredential = new AppCredential(['appId' => $appId]);
$consumerKey = $appCredential->getConsumerKey();

Proposed Solution

can we get example how to use getConsumerKey please?

Add/check compatibility with phpdocumentor/reflection-docblock:^5.0

phpdocumentor/reflection-docblock:5.1.0 gets installed by default when you spin up a new Drupal test environment from https://github.com/drupal-composer/drupal-project and this library currently only supports "phpdocumentor/reflection-docblock": "^3.0 || ^4.0", so the installed version has to be dowgraded to be able to install the https://github.com/apigee/apigee-edge-drupal and this library as its dependency.

Suggested solution:
Validate compatibility with the 5.x version and it is supported, add it to the compatibility this.

Add support to a new query parameter on GET /developers and /apps MGMT API endpoints

Just by playing with the Apigee APIs in Public Cloud I found a new query parameter which is supported on the above-mentioned endpoints: ids. As of today, it seems undocumented here and here but they are used by the MGMT UI.

Supporting this new filtering option could be useful for lazy/async loading information from Apigee Edge.

How does it work?
On both endpoints the ids parameter accepts a list of comma seperated UUIDs and it returns the related developer/app objects. If no match found for a UUID then no data is returned for that.

Remaining questions

  • Is it supported by Hybrid? Probably not...
  • Is it supported on other API endpoints? Did a quick sanity check and for example /apiproducts does not support either ids or names.

ApiResponseException class throwing error on returning string response.

Description

While installing Drupal 8/9 kickstart web installer throws Warning: array_key_exists() expects parameter 2 to be array, string given in Apigee\Edge\Exception\ApiResponseException->parseErrorResponse() on Configure Apigee Edge section.

Steps to Reproduce

  • Install D8 kick-start through composer
  • Run through web installer
  • On Configure Apigee Edge section installer throws error

Actual Behavior

On Configure Apigee Edge section installer throws Warning: array_key_exists() expects parameter 2 to be array, string given in Apigee\Edge\Exception\ApiResponseException->parseErrorResponse()

Expected Behavior

Installer runs without errors

Screenshots

image

Version Info

Drupal 8.9.14

Add support for Developer categories API calls

Is your feature request related to a problem? Please describe.
no.

Describe the solution you'd like
Add support for CRUDL developer categories via /mint/organizations/{org_name}/developer-categories endpoint. Currently, this is missing from the API client, if I remember correctly it was not added because developer categories API was (is?) marked as deprecated, yet as I can see it is still actively used. (At least on the project that I am working on at this moment.)

Add Google OAuth authentication

Use account key to create and sign a JWT (JSON Web Token) that is sent to the Google OAuth 2.0 Authorization Server, which returns an access token. The token can then be used in the authorization header (Authorization: Bearer TOKEN) in making calls to the API. When the token expires, the application repeats the process.

The `$endUnit` property is missing from `RatePlanRate`.

Describe the bug
When trying to load the endUnit property of the RatePlanRateRateCard and the RatePlanRateRevShare objects, the property isn't available.

To Reproduce
Load a rate plan with rates and try to access $rateCardRate->getEndUnit().

Expected behavior
$rateCardRate->getEndUnit() should return the end unit.

List API Products

Q A
Bug? yes
New Feature? no
Version 2.0.0

Actual Behavior

When using the getEntities() method on the ApiProductController the CpsNotEnabledException is thrown.

Expected Behavior

I expect to get a list of the API Products

Steps to Reproduce the behavior

    public function __construct(ApigeeClient $client)
    {
        $organization = config('config.apigee.organization');
        $this->client = new ApiProductController($organization, $client->getClient());
    }
    ...
    public function all()
    {
        return $this->client->getEntities();
    }

Notice in recent message logs if description is empty after creating app in Apigee hybrid

Description

Notice in recent message logs if description is empty after creating app in Apigee hybrid

Steps to Reproduce

Create an app with empty description

Notice: Undefined property: stdClass::$value in Apigee\Edge\Denormalizer\AttributesPropertyDenormalizer->denormalize() (line 57 of \vendor\apigee\apigee-client-php\src\Denormalizer\AttributesPropertyDenormalizer.php)

Deprecation warnings when called serialized classes from the Symfony framework 4.4.x.

Description

During the development of PHPUnit tests, I discovered deprecation warnings caused by SDK apigee/apigee-client-php.

Warnings

1x: Passing configuration options directly to the constructor is deprecated since Symfony 4.2, use the default context instead.

  • constructor with warning
    vendor/symfony/serializer/Normalizer/DateTimeNormalizer.php

    public function __construct($defaultContext = [], \DateTimeZone $timezone = null)
      {
          $this->defaultContext = [
              self::FORMAT_KEY => \DateTime::RFC3339,
              self::TIMEZONE_KEY => null,
          ];
    
          if (!\is_array($defaultContext)) {
              @trigger_error('Passing configuration options directly to the constructor is deprecated since Symfony 4.2, use the default context instead.', \E_USER_DEPRECATED);
    
              $defaultContext = [self::FORMAT_KEY => (string) $defaultContext];
              $defaultContext[self::TIMEZONE_KEY] = $timezone;
          }
    
          $this->defaultContext = array_merge($this->defaultContext, $defaultContext);
      }
    
  • cause
    vendor/apigee/apigee-client-php/src/Api/Monetization/Serializer/EntitySerializer.php

    new DateTimeNormalizer(EntityInterface::DATE_FORMAT, new \DateTimeZone('UTC')),
    

1x: Using constructor parameters that are not a default context is deprecated since Symfony 4.2, use the "json_decode_associative" and "json_decode_recursion_depth" keys of the context instead.

  • constructor with warning
    vendor/symfony/serializer/Encoder/JsonDecode.php

    public function __construct($defaultContext = [], int $depth = 512)
      {
          if (!\is_array($defaultContext)) {
              @trigger_error(sprintf('Using constructor parameters that are not a default context is deprecated since Symfony 4.2, use the "%s" and "%s" keys of the context instead.', self::ASSOCIATIVE, self::RECURSION_DEPTH), \E_USER_DEPRECATED);
    
              $defaultContext = [
                  self::ASSOCIATIVE => (bool) $defaultContext,
                  self::RECURSION_DEPTH => $depth,
              ];
          }
    
          $this->defaultContext = array_merge($this->defaultContext, $defaultContext);
      }
    
  • cause
    vendor/apigee/apigee-client-php/src/Serializer/JsonDecode.php

    parent::__construct($associative, $depth);
    

1x: Passing an integer as first parameter of the "Symfony\Component\Serializer\Encoder\JsonEncode::__construct()" method is deprecated since Symfony 4.2, use the "json_encode_options" key of the context instead.

  • constructor with warning
    vendor/symfony/serializer/Encoder/JsonEncode.php
public function __construct($defaultContext = [])
    {
        if (!\is_array($defaultContext)) {
            @trigger_error(sprintf('Passing an integer as first parameter of the "%s()" method is deprecated since Symfony 4.2, use the "json_encode_options" key of the context instead.', __METHOD__), \E_USER_DEPRECATED);

            $this->defaultContext[self::OPTIONS] = (int) $defaultContext;
        } else {
            $this->defaultContext = array_merge($this->defaultContext, $defaultContext);
        }
    }
  • cause
    vendor/apigee/apigee-client-php/src/Serializer/JsonEncoder.php
     parent::__construct(new JsonEncode(JSON_PRESERVE_ZERO_FRACTION), $decodingImpl);
    

Version Info

Symfony: 4.4.x
Drupal core: 9.1.7
apigee/apigee-client-php: 2.0.7

Support PSR-17 and PSR-18 interfaces and php-http 2.x packages

Preface

First PSR-17 and later PSR-18 accepted and PHP-HTTP libraries has started to update their code to rely on new interfaces and add return types to their methods. New major versions got released from these libraries because these changes caused BC breaks with the previous versions.

Problem

Libraries that we use:

  • php-http/httplug: php-http/httplug@v1.1.0...v2.0.0
    • We hare already used these return types so these are no BC breaking changes for this library.
  • php-http/client-common: php-http/client-common@1.9.0...2.0.0-RC1 (only RC1 is available at this moment)
    • Good news, this upcoming version is finally contains a proper fix for php-http/client-common#113 (implemented in php-http/client-common#141). Bad news, this fix is only available in the 2.x branch and it can not be back-ported officially to the 1.x branch. We could back-port this patch for this library but applying it would be only required if < 2.0.0 version is installed from php-http/client-common. Cweagans' composer patches (that we use and recommend) does not support version based patch restrictions (only vaimo's version has that feature) therefore applying this patch could not be automated. Patching the library would cause extra complexity for consumers. Consequently, it would be better to set the minimum requirement to the php-http/client-common:^2.0.
    • For the first sight, this new major release only requires some small changes in this library. Although, if you check these changes more closely then you can see they makes impossible to support both the 1.x version and the 2.x version from the library in the same time.
      • Different exception classes are being used in the Journal and History classes in the 1.x and 2.x version: php-http/client-common#163.
        • This could be fixed by not extending the Journal interface from the client-common in this library's JournalInterface interface and creating our own History plugin that depends on this library's JournalInterface and not client common's definition. That would cause an additional maintenance cost for us.
        • Or by implementing something like Nyholm suggeted: php-http/client-common#115 (comment)
  • php-http/guzzle6-adapter: php-http/guzzle6-adapter@v1.1.1...v2.0.1 This is only a dev dependency so it should not be a blocker, just added to the list for the sake of completeness.

Related conversion which contains some info about the maintenance and support of the 1.x (older) php-http packages and more: php-http/client-common#115 (comment)

Proposed solution

Because it seems there is no good way to support both 1.x and 2.x version from all required php-http libraries in the current 2.x branch therefore we should release a new major from this library. The new 3.x version should rely on PSR-17 and PSR-18 interfaces instead of interfaces provided by php-http/httplug.

New client implementations and consumers should use the PSR-18 interfaces directly. In the long term, we expect PSR-18 to completely replace the need for HTTPlug.

(From php-http/httplug's README.md)

The new 3.x version should support only 2.x versions from php-http/client-common and php-http/guzzle6-adapter (as dev dependency) libraries.

In addition, it seems we should wait for the release of the 1.6.0 from the php-http/discovery and depend on that: php-http/discovery#134.

The same resolution happens in case of the Mailgun library: mailgun/mailgun-php#522

Questions

  1. What should happen with the 2.x version? Should we abandon it completely and force developers to update to the 3.x version or mark it with a similar status like Drupal's "Maintenance fixes only". ? If we choose the second option, how long we should wait until we mark it as unsupported?

(This is a follow up on #24.)

Accommodate changes in error handling

The class Apigee\Edge\Exception\ApiResponseException needs to be updated to handle changes in error response from Hybrid:

{
  "error": {
      "code": 409,
      "message": "...",
      "status": "ABORTED",
      "details": [...]
  }
}

Installing Drupal 8/9 through Composer showing few warning with the Apigee X monetization Interfaces

Description

While installing Drupal 8/9 kick-start through composer, few warnings shows up in composer on Apigee X monetization Interfaces which says "doesn't comply with psr-4 auto-loading standards."

Steps to Reproduce

Install Drupal 8/9 by running - composer create-project apigee/devportal-kickstart-project:8.x-dev MY_PROJECT --no-interaction

Actual Behavior

Installation completes successfully but shows few warning on composer as ApigeeX interfaces "doesn't comply with psr-4 auto-loading standards."

Expected Behavior

Install drupal without any errors/warning for Apigee X files.

Screenshots

image

Version Info

Drupal 8/9

Hybrid API endpoint parameters should be URL encoded

A request to the Hybrid API of the type /organizations/{{organizationsId}}/developers/{{developer_email}} will return a 404 if the developer email contains an invalid character such as "+". Hybrid API requires such parameters to be URL encoded.

Example of failing request: /organizations/{{organizationsId}}/developers/[email protected]
Example of correct request: /organizations/{{organizationsId}}/developers/user%2B1%40example.com

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.