As I understand it, REST Api is an external interface for working with data. And how is the work inside the application? To contact from the code by external link for a piece of data instead of direct access to the database, in my opinion, a stupid idea.

Rags do not throw, if the question is stupid, I'm just at the beginning.

Let's say that in order to display the list on the page, we make a get request

api/users

which returns us json. And inside the application, how does it happen? Maybe you just need a method to access the method in "his language"? Like this:

$users->get('users')

  • Honestly, over the past few days I have read so much, that there is a mess in my head. Maybe someone here will give a few lessons (it is possible and not free), it is possible via Skype, m? - hcuser

1 answer 1

REST is for client-server applications. There is a backend and a frontend, where the first just defines the REST service, and the second does the mapping.

Here's an example: I have a website and a mobile application, but there is a server with a database. So, the site and the application are the data representation and each does it in its own way, but both are based on the data provided by the service, which is directly connected to the database.

If the application is built on models (entities), which is good, then the code will be something like this

 $users = UserRepository::find()->where('role'=>'online_access');

But it may look differently, depending on what the architecture is, etc. In general, the essence is that the backend works with the database and data, then leads them to some sort.

UPD. Here's an example of a working method from a REST service.

 /** * All * Lists all Users (available for roles with code LIST_ACCESS) * * @throws EmptyResponseException If no user was found * @throws ForbiddenHttpException If role code LIST_ACCESS not available * * @return array of users */ public function actionAll() { /** @var User $user to find */ $user = User::findOne( [ 'token' => $this->getToken() ] ); /** If no data was fetched */ if (is_null($user)) { throw new EmptyResponseException; } /** @var Role $role of fetched user so we can decide, is that page available or not */ $role = $user->getRole(); /** Check section access to view other profiles */ if (!$role->hasSectionAccess(self::LIST_ACCESS)) { throw new ForbiddenHttpException("Access denied for this user"); } /** Fetch all users */ return $this->response(User::find()->all()); }
  • It's clear. It is not clear another. Suppose two cases: you need a list for the presentation, and the same list for some manipulations inside the code. I will be right if I say that duplicating two identical queries to the database does not make sense? Then, if there is an external interface for receiving data, which is linked to the database, then how these same calls will be implemented in the application code? A few days already I read about rest, and each time the examples concern only the external interface, and not a word about the internal work. (( - hcuser
  • one
    @hcuser, look. Abstracted from requests. Suppose we have a users table. Then we create a class User , in which properties are table attributes. For example, users - id | name users - id | name , then the class class User { public $id; public $name;} class User { public $id; public $name;} , which is an Entity . Many ORMs are able to create it themselves, and some of the classes can make the structure of the database. And then you will no longer have requests as such. You will write the code, as in the answer, without using sql in the code. Read: [doctrine] [1] [1]: doctrine-orm.readthedocs.org/en/latest/tutorials/… - stck
  • Well, based on the example above and what has been said now, in essence, it turns out. For the processing of requests through the external interface and requests from the code are responsible, ultimately, the same functions. Only in the case of rest api there is an intermediary who parses the URI, accesses the database for the result, converts it to JSON, XML or something else that the user requested. Right? Concerning a DB. Now I have everything in the old manner, bare requests. I understand that using doctrine, PHP PDO or something similar in meaning is a matter of taste? - hcuser
  • @hcuser 1. "PDO" should be at the bottom. Just because it is abstraction from the database engine. 2. Doctrine, various implementations of ActiveRecord - this is a high-level shell, inside which PDO still lies. - etki