Operations

Operations are the methods you call on a service. Each operation has a unique name, endpoint, and HTTP method.

Specifying operations in the main description

The operations config should use the operations key in the master description array. It should then be a keyed array where the key specifies the name of the operation.

Example of a doSomething method:

// Master description array
[
    ...
    'operations' => [
        'doSomething' => [
           ...
        ]
    ]
]

Top level attributes

Name	Value	Required	Description
httpMethod	string	yes	GET, POST, PATCH, PUT, DELETE
uri	string	yes	URI of the operation. If this is relative, it will be merged with the description baseUrl. The uri attribute can contain URI templates. The variables of the URI template are parameters of the operation with a location value of uri.
parameters	array details	no	Parameters of the operation. This defines the input data for your operation, and how that data should be used in the HTTP request.
additionalParameters	array	no	Rules for any input parameter supplied to the operation without being explicitly defined.
cache	array	no	Override caching defaults
options	array	no	Guzzle request options. Will override any options set in the master description array. See Guzzle docs.

Cache overrides

Once caching it setup in the master description, SDK will automatically cache all cacheable operations to use as a fallback for when the service is unavailable.

By default a "cacheable" operation is a GET request. Other HTTP methods are assumed to be modifying data, and uncacheable.

You can override this default in either direction. By indicating that an operation is cacheable even though it has a different HTTP method:

'doSomething' => [
    'httpMethod' => 'POST',
    'cache' => [
        'fallback' => true
    ]
]

Or you can disable fallback caching on a GET request:

'doSomething' => [
    'httpMethod' => 'GET',
    'cache' => [
        'fallback' => false
    ]
]