Add a Repository and data interfaces and a webapi.xml

[astorm]

From vinai

Any plans to add a Repository and data interfaces and a webapi.xml features? With all this headless Magento flying around I think it would be liked.

[astorm]

what’s the best way to represent a CRUD model in webapi.xml

and "Repository and data interfaces” — what’s involved with that, exactly

[Vinai]

Writing an answer turned into a kind of blog post. I actually added it to my blog, but also as an answer on SE, hope it's useful since I believe there are many questions around this topic:

http://magento.stackexchange.com/a/160617/766

[astorm]

Blog Post: http://vinaikopp.com/2017/02/18/magento2_repositories_interfaces_and_webapi/

[astorm]

Thanks for your comments here, and in the Pareon Slack @Vinai. I think what we're going to do here is

1. Create a command (magento2:generate:webapi) that will create an empty skeleton with a webapi.xml, Interfaces, and Concrete Classes needed.

2. Add an option to that command that allows you to provide the name of a CRUD model. If present, this will populate the above Concrete Classes (and DTO interface) with the code needed so everything "just works"

3. A second command (magento2:generate:add_webapi_datavar) which will allow a user to provide a single data member name, and have that member name added everywhere it needs tobe for the webapi stuff.

Per the Slack conversation, I think it's best to keep this code somewhat separate from the CRUD generating code. Trying to cram everything in there seems like a path to confusion.

[Vinai]

That sounds amazing.
Do you have any thoughts on ExtensibleDataInterface/AbstractExtensibleModel vs AbstractModel?
Or do you think that is an advanced, uncommon use case that each developer can choose to implement manually? I think that would be a very good way to go actually.

[astorm]

@Vinai Re: AbstractExtensibleModel -- I'll need to think about that one. I haven't had a chance to use this new model type all that much so I'm not sure what the real world tradeoffs are.

It's also one of those areas that gets to the heart of a lot of Magento 2's current engineering challenges -- interesting architecture, but mostly undocumented code (http://devdocs.magento.com/guides/v2.0/extension-dev-guide/attributes.html isn't adequate) with no guarantee of backwards compatibility between versions of Magento. Boring as they might be, the fact that so much of M2's actual functionality still relies on the ported Magento\Framework\Model\AbstractModel classes means they're a safer choice for extension developers.

Something to think about for sure though.

[astorm]

@Vinai When/if you have a moment -- I'm working on a command that will generate a bare minimum "service contract" for a specific model. I'm still working out how the CLI interface will work but the master branch has a magento2:generate:service-contract that will generate a module with some hard coded values (in a module named Pulsestorm_Api2, for a model named Pulsestorm\Api2\Model\Thing.

I've also uploaded that generated module here

https://github.com/astorm/service-contract-example

Does the above module look OK from a "this demonstrates the service contract features for a single repository method and sample module? Or is it missing something considered vital to service contracts?

[astorm]

https://github.com/astorm/service-contract-example/issues

[astorm]

OK, latest code push (adjustments to boilerplate) builds out a better stock module. Here's what I'm thinking for next steps

• This command accepts a traditional CRUD model as a parameter
• Taking that parameter, the command builds out the boilerplate needed for a service contract implementation, including the webapi.xml file
• If the model implements an interface that looks like a data interface (how to determine this?), no interface gets generated. The current crud-model command will still generate an interface
• If the command needs to generate an interface, we will add the interface to the crud-model
• The command will generate a repository and repository interface -- the crud-model command will no longer generate a repository
• If needed, we'll setters and getters for getId to the model interface
• The repository will implement getById, save, delete, getList methods, per Magento de-facto standards.

Once this is done, we'll add a second pestle command for adding data properties to an interface. This will accept a prop_name and a type. It will also possibly parse existing crud model methods (and maybe schema updates or database tables?) for suggested fields). Doing this in a second command because trying to incorporate it into the first seems like an over-complication.

So that's the plan here -- if anyone has thoughts or other ideas, speak now or forever hold your grudges :)