There is a one-page web application written in plain PHP using JQuery and AJAX . Users in it pass authorization. Everything is done by the most common methods: sending the form to the server, checking the login / password, storing data in the session. All scripts accessed by JQuery contain a check of the session data that the user is authorized, and the execution result may vary depending on the user ID .

I want to rewrite everything using AngularJS . The question is how to properly organize interaction with the $http service. Should REST ideology be followed and how important is it, does AngularJS philosophy fit? Maybe you should think about developing an API and then refer to it already. Where to store user data if not in session. In principle, everything will work of course, but I want to do exactly that. Advise in what direction to dig, what to read is not abstruse (in clear written language)

UPD: I re-read and understood that it is necessary to specify the questions, but it turns out garbage.

  1. If I just store the user ID and password hash on the client (in $ scope variables) and use them when accessing the API, will this be the correct solution?

  2. I have a number of PHP classes that implement the data model (CRUD and all that) and the dispatcher scripts to which I access via jQuery (pass data to POST), they check the authorization, call the necessary methods depending on the parameters and return result (usually HTML). I understand that it will be correct to save the entire data model and make another "dispatcher" who will parse the request (method, URL, parameters passed) and also call the necessary methods depending on the situation to form a JSON response. Right? Correct if I am mistaken.

Offtop Che, I often get the idea that you need to throw PCPs and write backends on something normal

  • It seems that you already have the right view on the subject. - Vladimir Gamalyan
  • I hope to rewrite to 2 angular, the first is not a cake, very slow - Vasily Barbashev
  • @ Vasily Barbashev I rewrote already, a noticeable increase in speed is not visible with an unarmed look, but writing has become much more pleasant, considering also that TypeScript. - Vladimir Gamalyan
  • @VladimirGamalian means you didn’t write large applications, the first angular is just tin, it produced tons of binding - Vasily Barbashev
  • @ Vasily Barbashev wrote a very large application, about a million lines of js. If you follow the bindings and do not litter the page with hundreds of them, then everything runs very well. - Vladimir Gamalyan

1 answer 1

AngularJS does not contradict REST.

The scripts that jQuery accesses to you if they return JSON or XML are in essence already APIs, albeit not REST.

You can implement the authorization on the API, it is not stored in the session, it uses the token, for this you need to learn OAUTH 2.0, using it you can also tie the VK, Facebook authorization for your project.

UPD: answers to the UPD question.

We have 2 types of http requests. The first is requests whose result is the html page, the second type is api requests, the result will be in json format.

Authorization In php, the session is held using a cookie or if the cookies do not work, indicate the session_id in the request. The same principle can be used for api requests. When forming the api request in the angular service, we add the cookie values ​​to the request (if they are not added automatically) or if the cookies do not work, add the session_id. So the check of the rights of the api request will not differ from the check of the usual html requests and there is no need to create an additional authorization system.

What are the goals of the API?

If the goal is to create a data provider for third-party services, then it is advisable to use standards and documentation API, and authorization through OAUTH.

If the goal is to improve the interface response, then we use authorization such as I described above, REST is not necessary to follow, since You are a consumer of your api. But that would not get confused is better to use REST. Http delete and put requests should not confuse them is not difficult to handle.

To make it easier for the dispatcher to distinguish between html and api requests, implement the backend so that the API prefix has the prefix / api /

  • Yes, the fact that the scripts are API is clear, the whole question now is how to do it correctly. I read about OAUTH 2.0, but I’m not sure if it’s worth making a garden. Actually, I understood that it was necessary to specify the questions - Rick Walker
  • UPD Updated the answer - Marat Batalandabad
  • Thank. Now it's clearer. The purpose of the API is to work with it yourself. But I still want to do it according to the rules in order to firstly get a good experience, and secondly, to make it more pleasant and easier to work on the front - end - Rick Walker