We published the first document related to transition from api-tools to dotkernel api, the comparison between them.
If we missed some criteria for comparison, we are happy to extend this document.
The entire dotkernel APi documentation is still WIP .
I’ve to admit it is an impressive bullet-point documentation. People will going to love it just as much as they liked MVC. I’m crying with joy.
as much as they liked MVC ? 
I could minimize the documentation into five simple line and would say. Eureka I’ve solved it.
Then people would really loved it more than MVC. 
good idea, thanks for the feedback
issue created change the order of items in docs · Issue #3 · dotkernel/api-documentation · GitHub
Don’t get me wrong on this idea. The problem is, when you talk with someone what you like about Laminas or dislike about it. They just say it is very hard. Then you ask what is so good about Laravel. They say, composer install and you’ve a complete OAuth installed. Laminas has nothing like that. Therefore, Laminas is bad. Then I can only do this. 
The reason is that people don’t understand the usage of framework and the audience you’re trying to attract to yourself the Indians. Because they’ve a massive population. So, for them these things matters and at the end of the day either it is laravel or laminas there will be five thousand line of controller. But, you’ll get the download you need. 
Ok, now we upgraded documentation to be more straight to the point how to install it 
Wow, that’s a simple, well thought out Mezzio implementation. I took some time to have a closer look at the GIT repository. I noticed a few things.
Why a template engine is implemented in Dotkernel API? That 's a no-go for me, because I want to decide wether I need a template engine not I use the standard view implementation. Twig is just another dependency I or one of my customers have to maintain. I or one of my customers has to learn the Twig syntax to understand what 's happening in my or his templates. That 's a difficult implementation I 'd do without in the future.
Evaluating received header data is an important part of REST APIs. Either I was too quick and overlooked it, or it is completely missing here. Sure, I could implement it for myself. But it would be more complete, if Dotkernel API devlivers such a feature automatically. Ever thought of file uploads?
The overview shows that versioning of a REST API is not possible. Unfortunately, this is a huge showstopper. For professional enterprise developments, it is essential to be able to provide updates to endpoints via versioning.
Nice to see, that it is much easier with Mezzio than wiring all togehter with Lamians Api Tools. Although some relevant options are not yet implemented, it is a good point to start with simple REST APIs. Good work but shouldn 't be used for enterprise applications or other similar professional applications.
Thanks a lot, that’s why we are posted this App public, in order to get feeback.
Yeah, i know , a template engine should not be part of an API.
Still it is a practical integration based on past 6 years of experience, in which for each API we have built it was a need to send emails. That’s the only function of twig integration, to generate dynamically HTML body emails …
In practice, here and there, this functionality was replace with various calls to external services ( mailchimp, etc. )
Good, this is something that I need to come back to you .
Oh, versioning … The old story …
This is a pure REST API , ( or try to be ) , and we agree with the logic of the author of REST architectural style.
Versioning only introduce an unnecessary level of compelxity and dead code. If some really need versioning, for some obscure reason, then maybe is better to build a separate API…
Blockquote
The reason to make a real REST API is to get evolvability … a “v1” is a middle finger to your API customers, indicating RPC/HTTP (not REST)— Roy T. Fielding (@fielding) September 8, 2013
We are using this App for the past 6 years on few dozen production API’s, some are simple, some a bit more complex, and some are really “proffesional enterprise developments”.
The technical decisions that are visible now in Dotkernel API are the result of many iterations, and of 20 years of experience in building enterprise complex solutions.
But i agree, still this is suitable for small and medium applications.
And is only a starting point for building a simple API based on Mezzio.
Thanks again for your feedback !
I would not list or link this in any documentation or comparison if the software previously supported this and there is no alternative (e.g. this or that) in the current version. Or it is not described in detail what should be done instead or is even better.
Additionally, the following can also be found in the article from above:
If necessary, consider content negotiation, where a consumer includes in the Accept header the media type they expect. If the structure is significantly different, maybe it isn’t a new version of the API, just a new representation of the resource that the API returns.
The question is then who is giving the middle finger here.
Dotkernel API is not a continuation of api-tools.
And definitely does not and will not suport versioning, in api-tools style.
We are in process of studing api-tools and writing a migration document from api-tools to Dotkernel API .
There is no migration path, it need to be build from scratch and entities re-coded.
So yes, a new API built on Dotkernel API can be a so-called “new version” of the previous API built on api-tools.
Even if an old APi built on api-tools have multiple versions, can run as-is until the old versions are fade-out.
Agreed, content negociation is a different story here. And will be adressed asap.
Definitelly Dotkernel API does not want to compete with api-platform.
I do not want to complicate things unnecessary, i want to keep things simple as possible.
Yeah, i know , a template engine should not be part of an API.
Still it is a practical integration based on past 6 years of experience, in which for each API we have built it was a need to send emails. That’s the only function of twig integration, to generate dynamically HTML body emails …
In practice, here and there, this functionality was replace with various calls to external services ( mailchimp, etc. )
It’s not really a question of whether or not it should be an integral part of an API. You run the risk of falling into exactly the same trap as the Laravel Framework. Laravel gives you the freedom to use Blade. You can, but you don’t have to. Regardless of whether you use it or not, it is always there and must be maintained. In the end, it’s just an error-prone overhead that will cost you time and money.
In my opinion, it should be up to the developer to decide whether or not he wants to use such overhead in his implementation. My very personal opinion on template engines as such: The biggest no-brainer ever developed with PHP. You develop your own syntax to translate it back to PHP to do exactly what PHP was originally developed for and can still do smoothly. The only template engine that has a raison d’être for me personally is XSLT. If you’ve had good experiences with Twig, that’s good for you. Other developers may see it completely differently. Implement it as a suggest in the Composer configuration of the package. That would be awesome. Why not use laminas/laminas-view as a standard implementation?
Versioning only introduce an unnecessary level of compelxity and dead code. If some really need versioning, for some obscure reason, then maybe is better to build a separate API…
Versioning is fundamental. I have no idea how you have implemented changes to your API in recent years. An API can be connected to hundreds of clients with thousands of users. In such a scenario, there is no other way than to guarantee minor or major updates over a certain period of time with parallel operation of several versions. If an API is used by more than one client, there is no other way to roll out updates to the API. Imagine Google simply shutting down an old API when rolling out a new API. There are always transition periods with parallel operation. It makes no sense at all to always roll out a completely new instance of the API.
Unfortunately, there is a misunderstanding here, because in the end I don’t care whether versioning is available, I just wanted to point out the reference to the middle finger and a possible acceptance of the new solution when someone comes from the API tools.
The intention may be correct, but if I just say that something is wrong, even though half the market uses it that way, and then don’t show an alternative, then it probably doesn’t help the project itself very much.
I hope I was able to show you a little better what I meant.
Agreed, content negociation is a different story here. And will be adressed asap.
Ok, we updated the documentation, related to comparison between Dotkernel API and api-tools
Versioning
We address the problem by using Deprecations and evolution strategy
Content-Negotiation
this is under development right now , when we are ready in next days with it, will post an update
I read the article and it provides good information.
With the retirement of api-tools, the TSC has suggested that there should be an indication in the api-tools documentation (or somewhere else) that Dotkernel API is the recommended replacement.
It will be important, in my opinion, to state that Dotkernel API is not a one-for-one replacement but a potential alternate solution to migrate to from api-tools. Functionalities are not one-to-one and that’s expected since no one made reprensentations that it was. This is just to manage users’ expectations.
Migrating from api-tools to Dotkernel API is no small endeavor. In addition to finding solutions to missing api-tools functionalities in Dotkernel API, one also have to migrate from MVC to Mezzio, use Doctrine (if you are not already using it), etc.
I use api-tools components in my MVC apps and it worked great for my needs. I sometimes use the Admin UI to get started but I usually end up adding configs manually.
How may people are in the same situation? I am thinking that there might be some business case to keep some of these components alive (outside Laminas?).
And just to avoid an endless conversation, please do not reply that MVC is not the way of the future. I already know that but my point is that there are still MVC apps out there providing APIs.