Jump to content

organizing a PHP project geared towards API development


thescientist
 Share

Recommended Posts

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?
  • Like 1
Link to comment
Share on other sites

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/

  • Like 1
Link to comment
Share on other sites

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 by birbal
Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share

×
×
  • Create New...