Hi everyone, I’m the author of Aphiria (and Opulence, if any of you remember it). I wrote a Medium article summarizing what it is that I’ve been working on for three years and what differentiates it from other REST API frameworks for PHP. If you have any questions, ask away.
+1 for migrating to php from another language. Thats good
what difference between Opulence and Aphiria ?
I remember Opulence. Never used it, but I recall it being built pretty well.
It’s wonderful that you’re still contributing quality material to the Open Source community. I may give it a spin, since I also remember how nice .NET Core was to work with when it came to APIs.
API Platform has been something that I’ve been experimenting with. Are there any plans in taking this in a similar direction? Or do you plan on maintaining just the REST aspect and keeping this lighter?
We use api platform. Not huge fans of the way it was built. What are your thoughts?
I’m not opposed to extending it beyond REST, but I do want to keep it focused on API development rather than infrastructure logic (eg ORMs). The issue I ran into with Opulence was trying to do too much at once with a small community – it’s just impossible to keep up and continue to build quality features.
This looks pretty nice! I was so cool to see a lot of modern code, including PHP 8 attributes and PHP 7.4 short functions – exactly what I would love to see in a new frame from ground-up. Great documentation as well, and I wish sir all the best!
I really appreciate the kind words! Yeah, I was on the fence of requiring PHP 7.4 vs 8.0. Initially, I was using PHPDoc annotations rather than native attributes for things like routes, but with the release of 8.0, I felt it was good to adopt the future, even if the might lower the number of initial adopters.
Am i the only one who separatest a REST API from CRUD routes with json representation? I always wonder if i read such things.It’s the highest rank comment, and I have tried reading it a few times, but I am not sure what it means. Can you explain this? 🙂
This looks interesting. I’ve started on something similar though I built ontop of cakephp: https://mixerapi.com
You should do an openapi generator. It would make this even better. Here’s one I did https://github.com/cnizzardini/cakephp-swagger-bake
What’s the reasoning behind how you name your interfaces? Doesn’t psr say to name them SomeInterface?
I actually already have a roadmap item for this.
I agree – super useful for frontend devs.
As for how I name my interfaces, they’re prefixed with I (the Microsoft way, which I find less verbose). I believe the PSRs’ only guidance on how to name interfaces is with respect to the PSRs themselves, not to code outside of the PSR repositories.
Would you put this here? https://github.com/the-benchmarker/web-frameworks. Would love to see how it perform
I see you’re doing a monorepo to component setup. How are you handling the splits from the monorepo? I used this https://www.subtreesplit.com/ but there are few ways of accomplishing it.
In my opinion giving user ability to setup route for method is mistake. It may lead to very unorganised set of controllers. Imagine that I write controller with two methods, and define /user/:Id, and /account/:Id
Then, it will be a nightmare to find appropriate handlers.
Route should be defined for class instead, imo. And for each method in class you define which http method should it handle.
In this case, I’d argue you should have two controllers – UserController and AccountController because the two operate on different parts of your domain logic. Also, restricting controllers to only have one unique HTTP method per controller method would make it complicated to do things like UserController::getUserById(int $userId) and UserController::getAllUsers() – both are GET HTTP methods, but have different routes (/users vs /users/:id).