I think this is the reason why PHP is still so popular. Even with the latest 8.3 version these things still work - even though everyone else has moved to frameworks like laravel or fully OO code.<p>Sometimes you just want to get shit done for your personal weekend hobby projects and little things like this can be a tremendous help to make your MVP. Sometimes these MVPs can be super practical in real-life as well (1)<p>Writing code this way can sometimes be liberating and more fun like freestyle swimming. I still miss the days of writing native SQL queries instead of using the ORM for everything nowadays.<p>(1) <a href="https://twitter.com/levelsio/status/1381709793769979906?lang=en" rel="nofollow">https://twitter.com/levelsio/status/1381709793769979906?lang...</a>
Reading the code, this feels like a python developer writing PHP and frankly doing a bad job. Even the formatting seems to give up readability for line count for some unknown reason. There is no typing, no following of PSR-2 in anyway, and things which make my static analysis tools very unhappy.<p>A single file API is not a bad idea, but this is a bad implementation.
Nice! Here is my own take on the same idea (single file PHP api)<p><a href="https://github.com/prog-re/ugly/blob/main/docs/manual.md">https://github.com/prog-re/ugly/blob/main/docs/manual.md</a><p>Edit: I added links to Oink and Zaap from my readme.md. We could make a Single file PHP api framework webring!
Personally I believe that you should always use <i>require</i> (<i>require_once</i>) instead of <i>include</i> (<i>include_once</i>) to be sure that a failure to load file creates an <i>E_ERROR</i> instead of an <i>E_WARNING</i>, this both for loading the framework but also when the framework when loading the api file.<p><i>E_ERROR</i> is a fatal error thus it will throw (I think since PHP 7) an <i>Error</i> exception that can be catched with a normal try/catch and thus possible to return a proper response.
The title is quite confusing on what the project is. It should be "Oink: a single-file PHP library to easily build API" or something like that.<p>Appart from that, it's a nice project, but would benefit from better examples that actually needs an API to do things asynchronously, like a web app that needs to be able to synchronize with a server from time to time. Maybe a TODO list to keep the example short?
Because the blog and gallery examples are not really convincing: why would we depend on JS to render the page and almost do the job twice while the rendering could have easily be done in PHP directly?
Please god no. People might think this is what PHP looks like in real life while it's far from the good practices that are normally used in PHP since ages.
That's a gem! It reminds me why I used to love PHP: rapid prototyping, functional style. It's a shame that I don't use it for a long time.
That's a nice little project that I would use to quickly build an API for testing or developing an app, you just need the php executable to start it up.<p>But if I had to make one comment, after looking at the code, that serve function with that huge try/catch block is not the nicest thing to see, I would split it up and try to get some more meaningful exception and error handling.
Hey, nice! Here's my take on the same concept: <a href="https://github.com/aaviator42/zaap">https://github.com/aaviator42/zaap</a><p>Allows me to have an API with multiple methods and endpoints up and running in minutes. :)
All it really takes in PHP: <a href="https://github.com/gnat/api.php/blob/main/api.php">https://github.com/gnat/api.php/blob/main/api.php</a>
You don't need this PHP snippet:<p>To get the same functionality without the extra step, simply use PostgREST [1]<p>[1] <a href="https://postgrest.org/" rel="nofollow">https://postgrest.org/</a>