Closed letsbyteit closed 10 years ago
If you prefer a simple structure, I would recommend
|-- src
|-- lib
|-- public
|-- scratch
`-- vendor
Where
index.php
Note:- you can use
restler/framework
instead ofluracast/restler
additionally you can have
We have recently created laravel/database
which can be used to add database support for restler. We are planning to work on restler/eloquent
for a well integrated solution.
Our recent application used it and has the following structure, where the api classes are placed in app/controllers
. Remaining folders should be self explanatory!
|-- app
| |-- commands
| |-- config
| |-- controllers
| |-- database
| | |-- migrations
| | `-- seeds
| |-- models
| |-- start
| |-- storage
| | |-- cache
| | |-- logs
| | |-- sessions
| | `-- views
| |-- tests
| `-- views
| |-- layouts
| |-- mails
| `-- partials
|-- bootstrap
|-- lib
|-- public
| |-- css
| |-- downloads
| |-- fonts
| |-- images
| |-- js
| `-- packages
|-- scratch
`-- vendor
Thanks to @Arul-, that helps me a lot! I'm going to have an API only, so there is no need for MVC. So now, it's time for restructuring my code! :+1:
I have a directory for Restler, where I maintain the Luracast package with all of its included dependencies, for easy drop-in (except for the fixes/adaptations) upgrading, and then I have a separate folder for our own developed/maintained resources. I actually have 2 folders apart from the R3 base folder... 1 which holds API methods and other Libraries/SDKs, and one which includes other auxiliary applications, cron scripts, etc which are not Web-apis, but which can use the API methods. For this I have a custom autoloader file which basically includes my API vendor folder, and the R3 vendor folder to the include path, and then includes the R3 autoloader.
I use a "mainframe" class which instantiates classes/objects and re-uses them throughout the calls. This allows us to re-use DB connections on the same web call, etc...
Our web code and web frontend is completely separate, and we like it that way... I cringe on seeing that R3 is becoming less and less API specific and is trying to serve frontends now... :(
Unlike other frameworks which are tailored for web application development and do api as an add on
Restler is always API first, It's architecture does not add extra baggage when not needed.
We added HTML features when we wanted to fully support OAuth2 but then realised it can be used for lot more!
@RVN-BR if you are using Restler for just API, that's fine none of the web app stuff is loaded, they only take up some hard disk space on your server.
Features like Nav (Navigation) now looks like used only for creating menu, but they will also be used for automatically adding links to the API so that we can get the full glory of REST with HATEOAS :)
We haven't documented many of the new components and their potential yet, I'm sure @RVN-BR will appreciate the features when we do!
Sounds good Arul! As long as there is no extra baggage for modules not needed, that puts my mind at ease :)
One question I've always had... When we have a lot of API files (many api classes added), will this make all calls slower? i.e. does restler include all the files at every API call, or will it match the route and only include the required files to serve the requested API method?
thanks!
When Restler is running in debug mode, all API classes will be initialised.
Once you turn on production mode and routes are cached, only the called api class is initialised.
Hey guys! Can you please recommend a 'best practise' directory structure for a PHP application using restler? I'm really new to php applications and my structure seems very messy.
Also how a minimal package should look like, for instance I want to keep important files only for fast installation of my application (I need OAuth2, but Twig blows the package up, I think? But your code works fine with a twig template).
My current structure (if you can call it that):
You did awesome work!