Developing a Web Application Using AJAX + REST

Question

RESTful API

Hello!

There is a need for a deep refactoring of one rather complex web application. Now it is done in PHP using the MVC paradigm. Models are thick, controllers are thin, so refactoring should be relatively easy.

The application has, among other things, a JSON REST API that external services interact with. The API does not yet cover all the functionality, but in the future it is planned to expand the set of methods and, ideally, the sets of UI and REST API functions should match 100%, and therefore the idea arose to remake the application on AJAX, which will interact with this API in order to avoid the possible duplication.

I have heard quite a lot about such web applications, and in my opinion, this approach looks very promising.

I want to ask the Habra community for help - maybe you have heard about ready-made frameworks (or components), descriptions, common problems, best practices, etc ... If so, please share the information. I would be very grateful.

Answer 1

I can share my experience in this regard, maybe it will be useful to you. We were making a REST API for mobile clients (iOS, Android) and made a terrible mistake by making the first version of the application with an API originally designed for AJAX. As it turned out, the peculiarity of external clients is that we have no control over them: once launched, the application will send such and only such requests that are embedded in it, and with the reproduction of versions, the situation only becomes more complicated. Therefore, the API is forced to remain compatible, which turned out to be very undesirable and ugly when making changes to the logic and structure of the service. Further - worse. Since the API calls were made “flexible”, according to the “few commands - more settings” principle, many parameters were passed on the client side in advance (filters, number of elements per page, etc.). After deploying applications, these settings became unmanageable. Now, in the new version, these errors are taken into account with the help of an additional layer that implements the principle of "many commands, minimum settings": for each version of the API (separately for the site and versions of external clients) there are different wrappers, with the substitution of pre-prepared filters, checks and format issuance. This allows you to control the change in the logic of the behavior of external clients on the server, organize serialization and compatibility. with the substitution of pre-prepared filters, checks and output format. This allows you to control the change in the logic of the behavior of external clients on the server, organize serialization and compatibility. with the substitution of pre-prepared filters, checks and output format. This allows you to control the change in the logic of the behavior of external clients on the server, organize serialization and compatibility.

Answer 2

Restful in PHP is very sad. Especially when you start integrating it with something like backbone and you realize that you have to write a lot of strange code.
An open Rest api is a mandatory support for deprecated functions. And it's a great joy if customers stop using some of the old calls.
There is still some difference between ajax api and restful api, recently there was a good article with some errors.

Answer 3

Stdit , I still didn’t understand about the settings. On a client (a client in general, not necessarily a mobile one), I know two common options: 1) hardcoding parameters into the client code, so you can change the settings accordingly only by changing the code; 2) client settings are written to a file or database from where they are taken when the application is launched. So what's stopping you from storing a lot of settings for option 2? Code update is no longer required. In addition, the settings can generally be stored in a remote database, in fact, on the server. Therefore, without a specific example, it is not clear why one should strive to minimize the number of settings and increase the number of commands. Even more. What do we mean by "setting", and what is a "command" in the context of REST?