organizing a PHP project geared towards API development

[thescientist]

I only make the distinction that's it's intended to be used for API development because there will be no front end resources (JS/CSS/HTML/images/etc) in the project whatsoever.

 

Here's is the stack / tools I intended to run with:

• Apache
• PHP >= 5.3 (ideally 5.5 depending on the host)
• Phing - build manager (switching over from MavenPHP)
• Composer - package / dependency manager
• Slim - API Framework (maintained by composer)
• PHPUnit - Testing Framework (maintained by composer)

 

The end result of the build would be:

• .htaccess - routes API requests to index.php
• index.php - single point of entry to the API
• PHAR file - archive of needed classes from services, lib, and vendor

 

Given that, what kind of directory structure do you use for a PHP application? I was thinking of something like:

 

$ tree -a

.

├── .htaccess

├── build.xml

├── composer.json

└── src

├── main

│ ├── php

│ │ ├── index.php

│ │ ├── lib

│ │ ├── services

│ │ └── vendor

│ └── sql

└── test

└── php

├── lib

└── services

Another option is to stick with the Maven convention of organizing by domains/packages

$ tree -a

.

├── build.xml

├── composer.json

└── src

├── main

│ ├── apache

└── .htaccess

│ ├── php

│ │ ├── com

│ │ │ └── domain

│ │ │ ├── product

│ │ │ │ ├── Product.php

│ │ │ │ └── ProductController.php

│ │ │ └── user

│ │ │ ├── User.php

│ │ │ └── UserController.php

│ │ ├── index.php

│ │ ├── io

│ │ │ └── thegreenhouse

│ │ │ ├── api

│ │ │ │ ├── PaypalAPI.php

│ │ │ │ └── TwitterAPI.php

│ │ │ └── lib

│ │ │ └── Database.php

│ │ └── vendor

│ │ ├── PHPUnit

│ │ └── Slim

│ └── sql

└── test

└── php

├── com

│ └── domain

│ ├── product

│ │ ├── ProductTest.php

│ │ └── ProductControllerTest.php

│ └── user

│ ├── UserTest.php

│ └── UserControllerTest.php

└── io

└── thegreenhouse

├── api

│ ├── PaypalAPITest.php

│ └── TwitterAPITest.php

└── lib

└── DatabaseTest.php

What are your thoughts and preferences for your own project?

[thescientist]

I've also been reading up on new standards for autoloading and how it defines directory structure / project organization

https://github.com/php-fig/fig-standards/blob/master/accepted/PSR-0.md

http://www.sitepoint.com/battle-autoloaders-psr-0-vs-psr-4/

[birbal]

Root

|

| --project

| |

| |--Abstracts

| |--Models

| |--Controllers

| |--Templates

| | |

| | |--defaultTheme

| | |--Theme1

| |--Interfaces

| |--DB

| |--Exception

| |--Traits

| |--settings

| |--config

| |--Storages

| |--Locale

| |--Util

| |--test

| |--HTDOCS

| | |

| | |--JS

| | |--CSS

| | |--image

| | |--sitemap

| | |--index.php

| |--Data

| |

| |-Cache

| |-Image

 

Using this. Problem with it is Model number is getting higher and it is now troublesome to maintain. I thought All Abstracts,Exception,Interfaces,traits are used almost on every request. So it could be bulk included and other models could be included hardcoded where needed. At first i thought autoloading will have signficant performance penalty so i avoided it on current project. Previously i was using namespaces to parse to directory strucutre something like on the GIT link you posted. I thought it would take once to hardcode a file but autoload will be ran several times in an application lifetime. I belive i was pretty wrong. Found some benchmark on autoload and it seems good to use. Not to mention the convenience of autoloader. Currently I am willing to use namespaces and autloading in the current project. But this moment introducing it will have to make major changes in the application. Untill that i have to go with this. I am glad you take out the topic because I was looking for same kind of thing. I would need some specification or somethinglike that for file management (I am worst at managing anything. I get overwhelmed when things gets bigger).

I even thought seperating by domain. but I was confused what to put where. because some Domain model uses other domain model too. I think there is many more things to consider before i conclude anything.

Edited March 8, 2014 by birbal