chriskacerguis/codeigniter-restserver: REST Controllers for CodeIgniter 3

What chriskacerguis/codeigniter-restserver removes from a CodeIgniter 3 controller

CodeIgniter 3 routes by URL segment. It does not map GET, POST, PUT and DELETE onto different controller methods, and it does not negotiate a response format. If you build an API on plain CI3, you write that dispatch yourself in every controller: read the request method, branch on it, pick a status code, encode the payload, set the content type. The repetition is the problem this package addresses.

The README describes it as a RESTful server implementation for CodeIgniter 3 built from one library, one config file and one controller. The audience is narrow and specific: developers with an existing CI3 application who need to expose data over HTTP without migrating frameworks. If your project is not on CodeIgniter 3, the package has nothing to attach to.

How verb-to-method dispatch and the Format class work together

The mechanism is naming convention plus a base class. A controller extends chriskacerguis\RestServer\RestController, and the library reads the incoming HTTP method and appends it to the requested resource name to find the method to call. A GET request for users reaches users_get(). A POST request for the same resource would reach users_post(), if it exists. The README's example controller, saved as Api.php, answers two URLs: /api/users/ returns every user, and /api/users/id/1 returns the record with id equal to 1.

Parameters arrive through accessor methods rather than the raw superglobals. In the example, $this->get('id') returns null when no id was supplied, which is how the controller decides between the collection and the single record. Responses go out through $this->response($data, $status), which sets the status code and stops execution, so there is no separate return path to maintain.

Output encoding sits in a Format class. The README shows how to extend it: subclass chriskacerguis\RestServer\Format and add a to_ method for each format you need. The worked example is to_pdf(), which converts the payload to HTML through to_html() and then hands it to a PDF library. That design means format support is open-ended, but it also means any format you add is code you own and maintain.

Installing chriskacerguis/codeigniter-restserver and serving your first endpoint

The README states two requirements: PHP 7.2 or greater, and CodeIgniter 3.1.11 or later. Installation is through Composer, which the README calls the recommended route and which uses semantic versioning on Packagist.

composer require chriskacerguis/codeigniter-restserver

Adding the dependency is not sufficient on its own. The README notes that you must copy rest.php into your config directory, for example application/config. That file is where the package's settings live, and without it the library has no configuration to read.

In the controller, bring in the base class and extend it. The README says the use statement should come before any of your code.

use chriskacerguis\RestServer\RestController;

class Example extends RestController
{
}

From there, a resource method follows the users_get() pattern shown in the README: gather data, call $this->get('id') to test for a parameter, and hand the result to $this->response($users, 200) or a 404 payload such as ['status' => false, 'message' => 'No users were found']. A request to /api/users/ should return the collection; /api/users/id/1 should return the single record.

Where this package stops helping

The README does not document authentication, rate limiting, pagination, versioning or rollback, and none of those appear in the example controller. The 404 body in the sample is hand-written per branch, which is the pattern the package leaves you with: it standardises dispatch and encoding, not error semantics. Two controllers written by two developers can return two different shapes for the same failure.

The harder constraint is the framework version. The README opens with an important note that a 4.x beta exists on the development branch, with its own system requirements. That splits attention between two lines with different requirements, and it means the 3.x code you read here is the stable track for CI3 specifically. There is no documented migration path in the README from a 3.x controller to the 4.x beta, so the upgrade is not a version bump you can plan from this document alone.

CodeIgniter 4 resource routing as the real alternative

If you are choosing a framework rather than extending one, CodeIgniter 4 ships resource routing in the framework itself. The difference is architectural, not cosmetic. Here, the routing convention lives in a third-party library that you install, configure by copying rest.php, and extend when you need a new format. In CI4, resource routes are declared in the routing configuration and the controller is a plain framework controller, so there is no base class to inherit and no Format subclass to keep in step with the framework.

The trade-off runs the other way too. Because this package is a library, it can be dropped into a CI3 application that already exists, which is exactly what a framework upgrade cannot do cheaply. A team with a working CI3 codebase gets REST dispatch without touching the rest of the application. A team starting fresh gets a smaller surface area by using the framework's own routing.

Maintenance, release cadence and the MIT licence

The last push to the default branch was on 2026-05-19, so the repository is not dormant, but the release history is uneven. Version 3.1.7 was released on 2024-09-17, six days after 3.1.6 on 2024-09-11, and the release before that, 3.1.5, dates to 2023-07-29. Two releases inside a week followed by a long gap suggests patch work rather than a steady cadence, and the README's note about a 4.x beta on the development branch points development effort elsewhere.

The licence is MIT, and the repository root contains a LICENSE file alongside composer.json, src/, language/ and .github/. MIT is permissive and places few obligations on how you redistribute the code, but the practical question for an adopter is the same one the licence does not answer: which branch you are depending on, and how much of the Format layer you have customised, since your to_ methods are yours to maintain. This is a description of the licence terms, not legal advice; read the LICENSE file itself before relying on it.

Editorial conclusion

Adopt chriskacerguis/codeigniter-restserver if you already run CodeIgniter 3.1.11 or newer on PHP 7.2 or greater and want verb-to-method routing without rewriting your application. Do not adopt it for a new project: the README points to a 4.x beta on the development branch with different system requirements, and the 3.x line is tied to CI3. Before committing, verify which branch matches your framework version, confirm the licence file in the repository root matches the MIT identifier, and check that the response format you need has a to_ method or can be added through the Format class.

Frequently asked questions

Official sources

1. chriskacerguis/codeigniter-restserver on GitHub
2. Issues
3. License: MIT
4. README
5. Releases