## Handling Input

Since we're sending JSON back to the client application, it is only logical that we accept data in JSON format as well. CodeIgniter doesn't support this by default like Laravel does, as a matter of fact, CodeIgniter doesn't even support put and delete params. This is mainly because the framework is not intended for a RESTful service, however the effort that it takes to adapt it is minimal compared to the benefits, at least from my point of view.

So we will start by supporting the JSON data that BackboneJS sends. Create a new file inside the "core" folder, this time it is going to be named "MY_Input.php" and it will have the following basic structure:

Now every time we use $this->input in our application we'll be referring to this class, we will create some new methods and override a few existing ones. First off, we are going to add the support for JSON data, add the following method to the new class. $request_params is a static variable used to store the request string/data sent by the client. It is static in order to make it object independent so that we can access it from any controller at any given time. The data is obtained from the php://input stream rather than the $_POST global. This is done in order to obtain the data sent in via PUT and DELETE requests as well. Finally, the obtained payload is inspected to check if it's an array, a JSON encoded object, or a query string, and it's processed accordingly. The result is then returned as an object. For this method to work, we need to create the static $request_params variable, add its declaration to the top of the class.

### Handling Regular Requests

Next, we need to override the post method of the regular input class to use the new JSON payload instead of the $_POST global, add the following method to the new Input class. This is almost the same as the post method from the original CI_Input class, with the difference being that it uses our new JSON method instead of the $_POST global to retrieve the post data. Now let's do the same for the the PUT method.

And then we also need the DELETE method:

Now technically, there's really no need for these additional methods, since the post method can handle the params in the PUT and DELETE requests, but semantically it's better (in my opinion).

This is all we need for our custom Input class. Again we're ignoring edge cases here, like multipart requests, even though it's not very hard to handle those and still maintain the functionality obtained here, but, for the sake of simplicity we'll keep it just the way it is.

## Base Model

To end the extension of the core classes, let's create a base model that every model in the app will extend upon, this is just to avoid repetition of common tasks for every model. Like any other core class extension, here's our barebones base model:

This base model will only serve the purpose of setting and retrieving errors. Add the following method to set a model error:

As you can see, this method uses an instance variable $error, so let's add its declaration to the top of our base model class. Finally, to keep it structured, let's create the getter method for this property. ## Handling Sessions ### Session Controller For the last part of this tutorial, we will create the controller and model to handle user sessions. The controller for our session is going to respond to any POST request made to our Session resource, since the session can't be retrieved after creation, nor updated directly, this controller will only respond to POST and DELETE requests. Please note that sending any other request to the resource will result in a server error, we're not dealing with edge cases here but this could be easily avoided by checking if the method that's called exists in our MY_Controller file and setting a default method name if the resource doesn't support the request. Below you'll find the structure for our Session controller: Note that this controller is extending the MY_Controller class instead of the regular CI_Controller class, we do this in order to use the _remap method and other functionality that we created earlier. OK, so now let's start with the constructor. This simple constructor just calls its parent constructor (as every controller in CodeIgniter must do) and then loads the controller's model. The code for the save method is as follows. And then the code for the remove method: Both methods simply delegate the task at hand to the model, which handles the actual data manipulation. In a real world application, the necessary data validation and session checking would be done in the controller, and the common tasks such as session checking should be implemented in the base controller. ### Session Model Now let's move on to the session model. Here is its basic structure: Like the controller, this model extends the MY_Model class instead of the regular CI_Model class, this is being done in order to use the common methods that we've created earlier. Again, let's start with the constructor. In this case, we just load the Mongo_db driver, that we discussed earlier. Now we'll continue with the method in charge of destroying the session. In this method we check if there's a session for the given session_id, and if so we attempt to remove it, sending a success message if everything goes OK, or setting an error and returning false if something goes wrong. Note that when using the session_id we use the special method $this->mongo_db->gen_id, this is because like I mentioned earlier, IDs in MongoDB are objects, so we use the id string to create it.

Finally, let's write the create method which will wrap up part one of this tutorial series.

First of all, we check that there's a user associated with the given email. Then we decode the user's associated salt (which I'll explain in the second part of this series when we cover user registration) and check that the given password matches the user's stored password.

We then remove any previous session associated with the user and create a new session object. If we were checking the session thoroughly, we would add things like the user_agent, ip_address, last_activity field and so on to this object. Finally, we send back to the client the session and user IDs for the new session.

## Conclusion

This has been a rather long tutorial, we covered a lot of topics, and we have even more to cover yet. Hopefully by now you have a better understanding of RESTful or stateless services and how to create such a service with CodeIgniter, and possibly, you may have also picked up some new ideas that you can give to the framework's core functionality.