jk / restserver

A PHP REST server for providing a very light-weight REST API. If you want color highlighting support for TextMate, look here: https://gist.github.com/1149076

RestServer.php

Master branch	Develop branch

A PHP REST server for providing a very light-weight REST API. Very easy to set up and get going. Independent from other libraries and frameworks. Supports HTTP authentication. Supports AMF data if the Zend Framework is present for Flash clients.

As of Classification of HTTP-based APIs this implementation should be considered as an HTTP based type II type of an API. So it is not an academic version of a real RESTful API, but this is by intention, so it's easy to understand and install.

restserver's Issues

Release a the current version as 1.0

It would be easier for new people to use RestServer.php if there is a zip file to download.

Implement automatic CORS support

WIP

To support AJAX requests from other sites, we want to implement CORS-support.

If a controller does not have an OPTIONS route, restserver should take care of this and make that endpoint available to send the adequate headers to enable browser's preflight requests.

Symlink Issue

If multiple GJB API instances are used but are only symlinks, this line will always return the same value:

RestServer/src/JK/RestServer/RestServer.php

Line 93 in d5461a6

$this->apcCacheSuffix = crc32(__DIR__);

This will cause a 404 for the second instance onward if the ES indexes are also split.

Bug while sending params via POST with a valid Content-Type

That issue came up during the deployment of an AngularJS web app running within Firefox. The Firefox appended to the intended:

Content-Type: application/x-form-urlencoded

Header. A statement about the used encoding so it was sent as:

Content-Type: application/x-form-urlencoded; charset=UTF-8

which broke RESTServer, since it misinterprets the Content-Type thinking that the requester doesn't do a urlencoded, parametered request.

Generated documentation using a API description language

The source code as a documentation is fine if you're the only one who is using the API. But when you open up to third-party, the absence of a good documentation will render your API useless to others. Since jk/restserver manage its functionality via DocBlock comments it's straight forward to generate a comprehensive documentation from it.

I have something like http://swagger.io/ in mind. But other languages are already worth to consider.

Implement one or more of the following API specification/description languages:

• Swagger 1.2 Spec
• Swagger 2.0 Spec
• Apiary Blueprint Spec
• RAML 0.8 Spec

Filter, sanitize and validate input variables

As of today, you can specify GET parameters as input to your methods. There is no standardized why to do so for other HTTP verbs like POST, PUT and DELETE. You have to parse $_POST etc. by your self.

While implementing a more user friendly why for accessing input variables it's a good idea to think about security. There is some work in this field. I want to implement some kind of a plugin architecture to integrate https://github.com/Wixel/GUMP to do the filtering etc.

I want to achive something like this chunk:

/**
 * Search
 * 
 * search for something
 *
 * @url POST /search
 * @url GET /search/$value
 * @validate value required, alpha_numeric, max_len=100, min_len=4
 * @filter value trim, sanitize_string
 */
public function search($value='')
{
    # code...
}

Do something

Yeah right, do something.

Authentication

Create an interface for authentication concerns. So that's easier to support OAuth2 frameworks and HTTP basic auth.

Throw an exception if urlMap.cache is not writeable

Todos:

• Throw an exception if urlMap.cache is not writeable (only the case if APC is absent)
• If the exception is thrown make sure that the directory which isn't writeable is mentioned in the exception

Fix handling of RestException from RestServer class

For now something like

throw new RestException(404, 'something is missing')

is not proper handled in any case.

Methods with only optional params are improperly initialized

If you have a function, where all parameters are optional and you call it without any parameters, the parameters wouldn't initialized with their default values. Instead they get numbered default values (i.e. param1 → 0, param2 → 1).

/**
     * Unorderd params
     * @url GET /unorderd
     * @url GET /unorderd/$param1
     * @url GET /unorderd/$param2/test/$param1
     */
    public function unorderd($param1 = 'default', $param2 = 'default')
    {
        return array('param1' => $param1, 'param2' => $param2);
    }

• Reproduce issue
• Write unit tests covering this issue
• Fix issue
• Release new version number