Mantén la atención porque en esta reseña hallarás el resultado que buscas.Este artículo fue evaluado por nuestros especialistas para garantizar la calidad y veracidad de nuestro contenido.
Según tengo entendido, todas las interfaces definidas en la carpeta Api son los Contratos de servicio. Entonces, en cualquier lugar que se use la interfaz en lugar de la implementación real de la clase, se usa el Contrato de servicio.
Un ejemplo sería la implementación de este complemento aquí https://github.com/magento/magento2/blob/2.3.2/app/code/Magento/GiftMessage/Model/Plugin/OrderGet.php#L78
Usa
protected function getOrderGiftMessage(MagentoSalesApiDataOrderInterface $order)
en vez de MagentoSalesModelOrder
Los servicios (también llamados contratos de servicio) son uno de nuestros patrones de desarrollo centrales en Magento 2 para garantizar interfaces estables para una fácil personalización / extensión. Toman 2 formas en la base del código (ambas están anotadas con @api en la clase o métodos de clase para identificarlos como interfaces estables que puede personalizar o exponer como una API web): API o SPI. Las API se definen en la carpeta de API y adoptan dos formas: un servicio completamente refactorizado y solo un módulo solo de API.
Los servicios completamente refactorizados se reflejan en los módulos Cliente, Inventario, Impuestos y Cotización * (siendo el Cliente el servicio a emular, Cotización tiene áreas restantes que necesitan ser refactorizadas). Un módulo de API solo se puede ver en Catálogo, Ventas y CMS. Para servicios completamente refactorizados, solo debería tener que hacer un complemento en el método de servicio para afectar tanto a las API web como a la GUI. Para los módulos solo de API, necesitaría complementar el método de servicio para afectar las apis web, pero aún necesitaría hacer personalizaciones de estilo 1x para afectar la GUI.
Los SPI son básicamente interfaces dentro del código anotado con @api que son espacios previstos que implementarían terceros para proporcionar algunas funciones comerciales. Un ejemplo de un SPI (CarrierInterface) definido en el módulo de envío que implementaría en su módulo de envío (es decir, Ups).
El marco de servicios ofrece una serie de ventajas interesantes. Fácil exposición como una API web (y próxima publicación 2.0 a través de colas de mensajes) vi webapi.xml configuración (como estilo SOAP y REST). En el corto plazo (post 2.0) agregaremos llamadas de API (llamadas de sincronización o Webhooks si están configurados para disparar mensajes asíncronos) que se pueden administrar / exponer a través de la configuración. Instalaciones / actualizaciones más seguras: puede identificar situaciones problemáticas mediante programación (2 o más extensiones que implementan la misma interfaz). Personalización optimizada que afecta tanto a las API web como a la interfaz gráfica de usuario, ya que solo hay un método / servicio para personalizar (para un módulo completamente refactorizado o nuevos módulos / servicios creados por la comunidad).
Contratos de servicio de Magento
Básicamente, los contratos de servicio son solo un conjunto de interfaces y clases que protegen la integridad de los datos y ocultan la lógica empresarial. La razón por la que los clientes querrán utilizar esto es que el contrato permite que el servicio evolucione sin afectar a sus usuarios.
La razón por la que esta actualización es importante es porque cambia la forma en que los usuarios interactúan con los diferentes módulos. En Magento 1, no había buenas formas de interactuar con otros módulos. Con los contratos de servicio en Magento 2, puede acceder y manipular los datos fácilmente, sin tener que preocuparse por la estructura del sistema.
Arquitectura de contrato de servicio
La capa de servicio tiene dos tipos de interfaz diferentes: interfaces de datos e interfaces de servicio. Las interfaces de datos son objetos que preservan la integridad de los datos mediante el uso de los siguientes patrones:
They’re read-only, since they only define constants and getters.
Getter functions can contain no parameters.
A getter function can only return a simple object type (string, integer, Boolean), a simple type array, and another data interface.
Mixed types can’t be returned by getter functions.
Data entity builders are the only way to populate and modify data interfaces.
Las interfaces de servicio proporcionan un conjunto de métodos públicos que puede utilizar un cliente. Hay tres subtipos de interfaces de servicio:
Repository Interfaces
Management Interfaces
Metadata Interfaces
Interfaces de repositorio
Las interfaces de repositorio garantizan que un usuario pueda acceder a las entidades de datos persistentes. Por ejemplo, las entidades de datos persistentes dentro del Módulo de cliente son Consumidor, Dirección y Grupo. Esto nos da tres interfaces diferentes:
CustomerRepositoryInterface
AddressRepositoryInterface
GroupRepositoryInterface
Los métodos que tienen estas interfaces son:
Save – If there’s no ID, creates a new record, and updates what’s existing if there is one.
Get – Looks for the IDs in the database and returns a certain data entity interface.
GetList – Finds all data entities that correspond with the search criteria, then gives access to the matches by returning the search result interface.
Delete – Deletes the selected entity
DeleteById – Deletes the entity when you only have its key.
Interfaces de gestión
Estas interfaces contienen diferentes funciones de gestión que no están relacionadas con los repositorios. Aquí hay unos ejemplos:
AccountManagementInterface contains functions such as createAccount(), isEmailAvailable(), changePassword(), and activate().
AddressManagementInterface checks whether an address is valid by using the validate() function.
El número de patrones crece constantemente y, a medida que lo hace, es probable que se les agreguen algunas de estas funciones.
Interfaces de metadatos
Las interfaces de metadatos brindan información sobre todos los attributes que se definen para una entidad específica. Esto también incluye personalizado attributes, a la que puede acceder con la función getCustomAttribute ($ name). Estos personalizados attributes incluir:
EAV attributes – Defined via the administration interface for a local site. They can differ according to the site, which means that they can’t be represented in the data entity interface written in PHP.
Extension attributes, for which the extension modules are used.
Referencia:
https://www.interactivated.me/uk/blog/service-contracts-magento-2/
Recuerda algo, que puedes decir si diste con la respuesta.