Download the PHP package ict/api_one_endpoint without Composer

api_one_endpoint

Api one endpoint bundle allows you to create an api focusing on operations instead of resources. One endpoint is used as a resource and api looks into payload to extract what operation has to perform and what data needs to perform it.

Installation

Use composer to install this bundle:

Inputs and outputs

Inputs and outputs define operations I/O flow. Each operatios can require an input (if it needs data to perform it) and must define an output which will be returned back to the client. Input have to be sent as a POST Json request and must follow the next schema:

As an example, let's see how a SendPaymentOperation input could looks like:

As we can seein the above payload, we're sending an input which tells our api to perform SendPaymentOperation and use as data the following keys:

• from: Who sends payment
• To: Who receives payment
• Amount: How much money xxxx sends to yyyy

Outputs must be wrapped with an Ict\ApiOneEndpoint\Model\Api\ApiOutput object. As a parameters, ApiOutput receives data which will be returned to client and http code which will be used in the response. Data can be an iterable (if we want to return a collection of data) or an object. This bundles relies on symfony serializer to send a json response to the client.

Let's see the following examples:

First example returns an array of Hero objects as an output and second example returns PaymentDoneOutput object.

If you want to use symfony serializer groups in your outputs, you can use the third ApiOutput parameter to pass the group name

Defining input operations

Operation inputs must be defined creating simple objects with its getters and setters. You can use symfony validation constraints to define validation rules so your input must hold required and valid data. This bundle will validate input automatically and will throw an Ict\ApiOneEndpoint\Exception\OperationValidationException if validation fails.

As an example, let's see how a payment operation input would looks like:

Defining operations

Operations must implement Ict\ApiOneEndpoint\Contract\Operation\OperationInterface

Each operation must define the following methods (declared in OperationInterface):

• perform: Executes operation
• getName: Gets operation name
• getInput: Gets input class. When an operation is executed, payload data will be deserialized to the input class and also validated.
• getGroup: Gets operation group. We will cover it when seeing operation authorization.
• getContext: Gets the operation context. We will cover it when seeing operation context separation

Protecting operations

This bundle relies on symfony voters to protect operations. Take a look to the following voter:

If you want to protect you api from an autentication context (JWT token, user / pass) you can use symfony security

The bundle pass an Ict\ApiOneEndpoint\Model\Operation\OperationSubject as an attribute to the voter. This gives you access to operation name and operation group (if it's been defined in getGroup method). Groups could be useful when you want to grant access to a group of operations to certain role or roles. As an example, let's imagine you have the following operations:

• CreateAccount
• UpdateAccount
• RemoveAccount

If you would want to restrict access to admin role, you would have to return the same group in getGroup method and then check the group in your voter.

The operation subject contains the following information (as public and readonly properties):

• operation: Fully qualified operation class name
• operationName: Operation Name (Value returned by method getName)
• group: Operation group (Value returned by method getGroup)
• data: Data to perform operation

This bundle always check operation authorization by it's possible there are no voters defined or no voters supporting conditions. To avoid getting denied access when no voters executed, set the following access decision strategy in your security.yaml file:

You can find more information about access decision strategy in symfony docs

Sending operations to the background

In order to allow developers to configure some operations to be executed in the background, this bundle relies on:

• Symfony messenger
• Ict\ApiOneEndpoint\Model\Attribute\IsBackground attribute

Let's go back to SendPayment operation

When an operation is annotated with IsBackground attribute, it's execution will be performed in the background and the client will no have to wait until it finishes. It can be useful for operations which can take more time to finish. Sending an email or a payment would be examples of this kind of operations.

After an operation is sent to the background, a 202 (Accepted) http request is returned to the client with the following content:

If you want to delay the execution some time, you can add the delay property to the attribute:

It will delay the execution 300 seconds (5 minutes).

Let's see how you should configure your messenger.yaml file to queue operations:

With the above configuration, you will be able to route operations to your transport.

Events

After an operation is performed, this bundle dispatches an \Ict\ApiOneEndpoint\EventSubscriber\Event\OperationPerformedEvent so the developer can listen to it and execute some task, for instance sending a notification to the user

If you are interested on sending notifications to the user, consider using this symfony notifier

Operations contexts

As we can see before, OperationInterface has a method getContext which can returns an array holding the allowed contexts or null. Let's imagine we want to keep two endpoints: one for clients and another one for providers. If we want an operation to allow only client context, we would write getContext method as follows:

In the next section we will se how to set up an endpoint context.

The controller

Setting up your controller is a really easy task. Let's take a look

You simply have to create your controller and use trait \Ict\ApiOneEndpoint\Controller\OperationControllerTrait. Then use the method executeOperation passing to it $request, $serializer and $operationHandler as an arguments and your operation will be executed. What about we want to limit our endpoint to manage only client context operations? We only would have to pass the context name to the Context object constructor

Now, this controller would only execute client context operations.