[4.0] What about making it RESTful?

[sopitz]

I think this project is a pretty damn good way to secure an application. And it easily works out of the box with only ONE disadvantage: You can only use it in PHP projects.

One of the major benefits of a PHP project in my eyes is the ease of getting up and running. Why dont we use this advantage and port that script to another version. Let's have an restfull api that you can use in ANY project, regardless of platform or technology, which is still super easy to set up and get running.

What do you think? Bullshit idea or something worth to be discussed?

[panique]

Definitly a fantastic idea, but to be honest I don't have the skills to build a really professional thing. It's also a little bit out of scope of the php-application approach, so we might create a new repo for this.

[sopitz]

I think the logic itself would be the same. No changes to the core would be necessary. In my mind (I actually never converted a MVC to REST yet) we would only have to change the way people can reach the application and the way we answer. We wouldnt send HTML to a browser but xml/json to the calling application. The same would go for the calls external applications could perform.

Repository wise: DEFINITELY a new repo. The only things these two would have in common would be the "core" logic. (Maybe it would be necessary to decouple the pure login functionality from the MVC framework during the transition and split repos as well. But that should be discussed later as it has nothing to do with neither of the repos.)

[atdotslashdot]

I'm using my own fork but have been experimenting with some restful bits in my app - under certain conditions (if the view url is preceded by "/api/") I spit json data out.

I know the code is a little clunky but the top of my View->render function looks like this

...
if($GLOBALS['app']->output_json)
{
 if(!headers_sent()){
  header('Content-type: application/json');
        }

        if(isset($this->data))
        {
            $this->data=(object)$this->data;
        }
        if(isset($_SESSION["feedback_negative"]) && !isset($this->view->data->errors)){
            $this->view->data->errors=$_SESSION["feedback_negative"];
        }
         echo(json_encode($this->data));
         Session::set('feedback_positive', null);
         Session::set('feedback_negative', null);

        return;
 }
 ...

the view->data contains data specific to a particular view, usually an array of stuff extracted from a database in the controller.
I'm not suggesting this should be implemented as is but I'm wondering if it really is a new repo or just a tweak to View->render?

[sopitz]

I will have a look into your implementation soon. But I think it should definitely get its own repo as its a whole different way of how you cope with that login stuff. Its not something you should/could use stand alone then but rather embedded it into an application pool.

[atdotslashdot]

OK, but in my head it's not a whole different way . The server receives requests - it can either render html or json back to the client. The server logic should be identical in both cases. It's also useful way to keep model data separate in view/controller code....

1.Server receives requests
2.appropriate controller is called which extracts data from the model
3.the data is passed to the view which renders the data back to the client either in simple json arrays or wrapping some html round it.

As I said, I spit json out if the url is prepended with '/api/' but I'm sure there are other ways to swing the cat :-)

[sopitz]

I know. The difference regarding is identical. But still it's a different purpose and you should make sure only either of the ways is possible to allow authentication (single point if responsibility). Otherwise you see yourself trapped in issues trying to figure out if you want our code to behave in a platforms manner or if it's your own app. The rest-login would serve the purpose to be a platform. Hence it should be designed and not render HTML or any other frontend related things. (At least that's what I learned from bigger restful java projects I worked in!)
I think the interface should be the same for all calls (either HTML or json) but the implementation of the response layer would have to differ.

[panique]

New ticket for that: #519 (and then realized that this thread already exists) :)

[panique]

The new version will be 3.0, not 2.1 (as the changes are too big), so let's move this to 4.0!

[abmmhasan]

https://github.com/educoder/pest
https://github.com/jmathai/epiphany
https://github.com/evantahler/PHP-DAVE-API

First one is better though!
And a good reading here, http:https://coreymaynard.com/blog/creating-a-restful-api-with-php/
And 2 more library,
https://github.com/jacwright/RestServer
https://github.com/davidmpaz/rest-curlclient-php

[panique]

Hey, I'm currently "cleaning" the project a little bit and moving feature-requests like this to an own list inside the readme file (find it under the "future features" point). I hope you are okay with it, as most tickets here are new features and not really bugs or so.

My idea is just to avoid this project from getting oversized by too many features, so I'm closing the ticket, but for sure linking it from the readme in case somebody wants to implement this.

I hope you are all okay with this. :)