A new PHP (HTTPlug) based ESI Client

No longer developed.

Hi there,

I’m developing a new php based client for interacting with esi. The client itself isn’t http client dependent via the use of httplug.

At this stage of development I’m seeking community feedback in relation to what you would like to see from this project and of course anything that might be missing from the project, in addition to the usual code reviews and bug reporting.

Some things I’m particularity interested in:

  • Are you happy with stdClass being used as the return object over a json encoded string?
  • Is the documentation lacking in any way or some aspects unclear?
  • If yes to the above, is it that each method doesn’t have an example of how to use it via the expected parameters?
  • Would you benefit from the sami generated API documentation being hosted publicly by myself or is the php doc blocks within the source itself enough insight into a methods function?

Thank you for reading and I look forward to your feedback.

Github

2 Likes

Looks good, are you using codegen to generate this client?

Two questions I have is around the access_token, if the token is applied to the client, is it sent with non-authenticated endpoints? How would you change the token if you were doing multiple calls to the same endpoint for many characters?

Hey,

Thanks for the reply @EveDataRules

I wrote the library. The only aspect which is generated is the API docs which is handled by sami, I’m not a fan of the code generated by swagger.

To answer your first question. Yes it is sent if it’s supplied. However the token is sent in the header and correctly ignored by esi/ccp if not required, if this might cause an issue anyone is aware of please let me know! Taking the public search endpoint /search/, we can create an authenticated client and query perfectly fine.

$client = \AGrimes94\Esi\EsiClient::create()->authenticate('ACCESS_TOKEN');
$response = $client->search()->searchPublic('Anthony Karnelou', ['character']);

/*
     * Results in:
     * 
     * {#598 ▼
     *  +"reasonPhrase": "OK"
     *  +"statusCode": 200
     *  +"headers": array:19 [▶]
     *  +"body": array:1 [▼
     *      "character" => array:1 [▶]
     *      ]
     *  }
     */

However this authentication step isn’t required if you are only querying public endpoints, so the below also works perfectly.

$client = \AGrimes94\Esi\EsiClient::create();
$response = $client->search()->searchPublic('Anthony Karnelou', ['character']);

/*
     * Results in:
     * 
     * {#592 ▼
     *  +"reasonPhrase": "OK"
     *  +"statusCode": 200
     *  +"headers": array:19 [▶]
     *  +"body": array:1 [▼
     *      "character" => array:1 [▶]
     *      ]
     *  }
     */

To answer your second question. If you need to re-authenticate a client with a different character you can call the authenticate method again on the client passing in the string token.

This will remove the existing authenticate plugin (the plugin handles adding the header to the request) and create a new authenticate plugin with the new information. Therefore subsequent requests will use the new access token.

An example:

// Create a client with our first characters token
$client = \AGrimes94\Esi\EsiClient::create()->authenticate('FIRST_ACCESS_TOKEN');

// Perform an authenticated request
$response = $client->search()->searchPrivate(123123123, 'Anthony Karnelou', ['character']);

// Change the access token in the created client
$client->authenticate('SECOND_ACCESS_TOKEN');

// Perform new request with different token
$response = $client->search()->searchPrivate(123123123, 'Anthony Karnelou', ['character']);
1 Like

Hey, please see the new post. I don’t think I hit reply correctly. Sorry. :confused:

I’m not sure if it would be worth changing, but the access token is a request parameter. It could get messy if someone was trying to perform concurrent requests with different tokens.

Just food for thought, it is a very nice looking library.

1 Like

Certainly a valid concern. I think I’ve only seen one library which checks each end point before a request is formed - at least I believe it does - and then sends the token only if that endpoint requires it as a request parameter (the access token itself should be sent as a header, and only as a request parameter if a header cannot be set, you can see this in the esi docs and also labelled as such on the esi homepage as “Access token to use if unable to set a header”, when looking at any endpoint where access_token is required).

In the aforementioned library however a configuration still has to be sent to the client making the requests for each individual user, setting the access_token each time for each user.

However, I really appreciate the feedback and I’m happy you’re happy. I’ll look into making the library more understandable - it’s still in development after all - and also to try filter token usage if a query doesn’t require it.

1 Like

I have added what is in essence API documentation to the read the docs. In addition to altering the readability a lot.

This is by no means an alternative to sami docs but is a major step towards making sure the library is as accessible as possible at the current stage. More improvements soon!

I have moved the repository to an organization. I am, and have been for a long time been planning a range of tools targeted towards eveonline.

As such, I feel it’s only suitable that I keep them together when they come to fruition.

More to follow on esi-client as it nears it’s 1.0-beta release!

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.