emslade / interactive-service-description Goto Github PK

Guzzle moved to a new doc hosting platform for their site. Need to update the links accordingly. The link to http://guzzlephp.org redirects to http://docs.guzzlephp.org/en/latest/ and the other link gets a 404.

Will not display inputs or Try it! button.

In a Guzzle service description it's possible to set the URI of an operation to an absolute uri, when the end-point for a particular operation is not just a relative path from the baseURL e.g.

 //Service level
 'baseUrl' => "https://api.github.com",

 //Operation level
 'uri' => 'https://github.com/login/oauth/access_token',

The operations that are defined with an absolute URI are groups under "https:"

Expanding this shows the actual operations:

which probably should have been grouped under 'user' and 'login'.

cheers
Dan

I realise it's not going to be a high priority for you guys, as you presumably have nice big monitors, but it would be great if you supported a bit of responsive design for us peons who are on 13" laptops.

For the operation below, it has ten possible parameters but only 4 are visible at once for me.

Currently it seems that the javascript compiles all the parameters into a uri, header parameters and params. It would be better if instead of doing that, the operation name was sent to the server, along with the raw parameters and then allow Guzzle to create the actual operation from the parameters.

This would make it easy to allow the Guzzle features of:

sentAs - Parameters can be sent as a different name to how they are named in the service with the sentAs property.

Filter params - Parameters can have a filter property which modifies the parameter between when it is submitted to guzzle and when it is sent to the actual api. https://guzzle3.readthedocs.org/webservice-client/guzzle-service-descriptions.html#filters

Response class - Some operations can require a bit of processing after the response is received, due either to the responseModel option being used, or the guzzle client being extended to account for the API provider 'bespoke'* implementations of Oauth, or any other reasons why the direct result of the API call needs to be poked a bit after being called.

Secure parameters - Some parameters shouldn't be sent to the client, and can only be set on the server e.g. oauth tokens or api secret keys should only live on the server.

All of the above should be easy to support/allow just be sending the operation name with the raw commands. e.g. something like ee4b8f2

The proxy should then be able to build the complete operation from the raw params.

btw you don't have a license file in this project....

*aka buggy