Download the PHP package transfuse/codeigniter-restserver without Composer
On this page you can find all versions of the php package transfuse/codeigniter-restserver. It is possible to download/install these versions without Composer. Possible dependencies are resolved automatically.
Download transfuse/codeigniter-restserver
More information about transfuse/codeigniter-restserver
Files in transfuse/codeigniter-restserver
Package codeigniter-restserver
Short Description A fully RESTful server implementation for CodeIgniter 2 and 3 using one library, one config file and one controller.
License MIT
Homepage https://github.com/transfuse/codeigniter-restserver
Informations about the package codeigniter-restserver
CodeIgniter Rest Server
A fully RESTful server implementation for CodeIgniter 2 and 3 using one library, one config file and one controller.
Originally from: (https://github.com/Hanisch-IT/codeigniter-restserver).
Requirements
- PHP 5.4 or greater
- CodeIgniter 2.0+
Installation & loading
Rest Server is available via Composer/Packagist (using semantic versioning), so just add this line to your composer.json
file:
or
Handling Requests
When your controller extends from REST_Controller
, the method names will be appended with the HTTP method used to access the request. If you're making an HTTP GET
call to /books
, for instance, it would call a Books#index_get()
method.
This allows you to implement a RESTful interface easily:
REST_Controller
also supports PUT
and DELETE
methods, allowing you to support a truly RESTful interface.
Accessing parameters is also easy. Simply use the name of the HTTP verb as a method:
The HTTP spec for DELETE requests precludes the use of parameters. For delete requests, you can add items to the URL
If query parameters are passed via the URL, regardless of whether it's a GET request, can be obtained by the query method:
Content Types
REST_Controller
supports a bunch of different request/response formats, including XML, JSON and serialised PHP. By default, the class will check the URL and look for a format either as an extension or as a separate segment.
This means your URLs can look like this:
This can be flaky with URI segments, so the recommend approach is using the HTTP Accept
header:
Any responses you make from the class (see responses for more on this) will be serialised in the designated format.
Responses
The class provides a response()
method that allows you to return data in the user's requested response format.
Returning any object / array / string / whatever is easy:
This will automatically return an HTTP 200 OK
response. You can specify the status code in the second parameter:
If you don't specify a response code, and the data you respond with == FALSE
(an empty array or string, for instance), the response code will automatically be set to 404 Not Found
:
Configuration
To override the default configuration you have to create a "rest.php" configuration file in your application/config path.
Authentication
This class also provides rudimentary support for HTTP basic authentication and/or the securer HTTP digest access authentication.
You can enable basic authentication by setting the $config['rest_auth']
to 'basic'
. The $config['rest_valid_logins']
directive can then be used to set the usernames and passwords able to log in to your system. The class will automatically send all the correct headers to trigger the authentication dialogue:
Enabling digest auth is similarly easy. Configure your desired logins in the config file like above, and set $config['rest_auth']
to 'digest'
. The class will automatically send out the headers to enable digest auth.
If you're tying this library into an AJAX endpoint where clients authenticate using PHP sessions then you may not like either of the digest nor basic authentication methods. In that case, you can tell the REST Library what PHP session variable to check for. If the variable exists, then the user is authorized. It will be up to your application to set that variable. You can define the variable in $config['auth_source']
. Then tell the library to use a php session variable by setting $config['rest_auth']
to session
.
All three methods of authentication can be secured further by using an IP whitelist. If you enable $config['rest_ip_whitelist_enabled']
in your config file, you can then set a list of allowed IPs.
Any client connecting to your API will be checked against the whitelisted IP array. If they're on the list, they'll be allowed access. If not, sorry, no can do hombre. The whitelist is a comma-separated string:
Your localhost IPs (127.0.0.1
and 0.0.0.0
) are allowed by default.
API Keys
In addition to the authentication methods above, the REST_Controller
class also supports the use of API keys. Enabling API keys is easy. Turn it on in your config/rest.php file:
You'll need to create a new database table to store and access the keys. REST_Controller
will automatically assume you have a table that looks like this:
The class will look for an HTTP header with the API key on each request. An invalid or missing API key will result in an HTTP 403 Forbidden
.
By default, the HTTP will be X-API-KEY
. This can be configured in config/rest.php.
Language settings
The default language is english. You can change the language in your rest configuration file (see above). To create or override the default language you have to create "rest_controller_lang.php" in you application folder (german/rest_controller_lang.php)
Other Documentation / Tutorials
Contributions
This project was originally written by Phil Sturgeon and Chris Kacerguis.
See: https://github.com/chriskacerguis/codeigniter-restserver