Magento2: Implement Web API and Service Contracts for Newsletter module

[ishakhsuvarov]

Newsletter module has no Service Contracts and therefore Web API capabilities. Little amount of information is available via API for Customer module but it does not cover most of the use cases.

To Do

• Design Service Contracts for the Newsletter module
• Implement all of the designed services
• Cover with tests, specially api-functional
• Possibly refactor some of the internal logic to use newly created services.

[davidverholen]

@ishakhsuvarov I would like to work on this I think. First step would be a proposal for the API layer? As PR maybe?

[ishakhsuvarov]

Hi @davidverholen
Yes, I assume proposed interfaces would be a great starting point. Feel free to do it in any comfortable way. PR is good as we can discuss and update it in the process, hopefully delivering it to the core at the finish.

[davidverholen]

@ishakhsuvarov just a design question:

Especially for the Newsletter Module it often would make sense to completely replace the default implementation (store users directly at external provider instead of magento db).

Do you think the service contract and the default implementation should be 2 dedicated modules? This way, the default implementation could be completely replaced by a custom implementation using composer.

[ishakhsuvarov]

@davidverholen This idea looks really reasonable to me.

[davidverholen]

@ishakhsuvarov to keep BC the original module must stay in the Magento\Newsletter namespace.

I could make a first proposal introducing a new Module only containing the API Layer (if the idea is not approved, I just move the Interfaces into the Newsletter Module).

2nd step would be to require the api module in the Newsletter module and implement the services using the current / given models.

A 3rd party vendor could then create a newsletter implementation, which completely replaces the original implementation which would reduce the amount of unused code in the installation.

3rd step might be searching for opportunities to refactor the implementation based on the new service layer while keeping BC.

Side question: Max told us on Mage Unconf, that there are already guidelines present for example regarding BC changes, but they were not publicly available by then. Has there been any progress on that?

[ishakhsuvarov]

The idea to introduce the separate module solely for the Service Layer looks awesome, however it may need some additional approvals (I'm pretty sure its doable).
As of "3rd step" – we can definitely work together on that one, since we already developed some practices on refactoring the legacy code in BC way, and may be you have some fresh ideas worth sharing :)
Regarding the guidelines for BC changes, the most complete guide is not yet published, but will be soon enough.

Thanks!

[davidverholen]

@ishakhsuvarov just one more question: can i already use php7 strict types in develop?

[ishakhsuvarov]

@davidverholen Sadly it is not possible at the moment due to multiple reasons, for instance Magento code generation is not ready for the strict types yet.

[davidverholen]

@ishakhsuvarov allright, I created a module with the most basic api I could think of as a discussion baseline.

For the Subscription entity, I think the target marketing channels should also be in the default interface. Maybe as a list which can be empty if only one marketing channel exists.

For the subscribe method there could be some additional exceptions I think.

I just saw, I added a SearchResultsInterface, but I can't think of a reasonable case where I should search for multiple Subscriptions, or am I wrong?

[EDIT] The last one was stupid. Of course I need a get list function to show them in the backend or to export the subscriptions

[magento-engcom-team]

Hi @davidverholen thank you for working on this. We are looking for PRs from you 👍
Closing this issue