В предыдущей лекции
мы узнали о REST API.
Вы видели, как конечные точки REST API
поддерживают способ получения клиентским приложением
данных с сервера или загрузки данных на сервер с помощью различных операций HTTP.
В этой лекции и упражнении, которое следует за этой лекцией,
мы рассмотрим, в частности, какую поддержку
поддерживает Express для проектирования и внедрения сервера на основе REST API.
В частности, мы также рассмотрим экспресс-маршрутизатор,
и как он позволяет нам разделить наше приложение, а
затем организовать его в несколько мини-Экспресс приложений,
которые объединяются, чтобы сформировать приложение Express, в
частности, когда мы имеем дело с различными REST API и частей.
Таким образом, подытоживая, в предыдущей лекции
мы подробно рассмотрели REST.
Мы также рассмотрели, как каждая конечная точка идентифицируется URI,
и как мы можем указать различные операции, которые должны быть выполнены на
каждой конечной точке, используя соответствующий
HTTP-глагол, GET, PUT, POST или DELETE.
Теперь в этой лекции
мы рассмотрим, как Express поддерживает разработку сервера REST API.
Мы рассмотрим поддержку Express для различных вопросов, таких как app.all,
app.get, put, post и delete,
и как эти методы могут быть использованы для создания сервера REST API.
В Express различные группы приложений могут быть определены с помощью приложения,.
и различные методы.
Таким образом, app.all указывает операцию, которая должна быть выполнена на всех различных глаголах,
on, in и part.
Так, например, в этом примере
мы видим, что конечная точка определяется /dishes,
и поэтому app.all, что указано в функции, которая дана для app.all,
будет применяться ко всем входящим запросам.
App.get указывает, что должно быть сделано для запросов GET и,
соответственно, для
запросов POST, PUT и DELETE, которые отправляются в конечную точку /dishes,
как показано в этом примере.
Экспресс также поддерживает определение конечных точек с помощью параметров.
Так, например, вы можете указать конкретный идентификатор блюда, если хотите,
а затем разрешить операцию для
конкретной конечной точки, относящейся к конкретному блюду с заданным идентификатором блюда.
Таким образом, в этом случае в
качестве параметра задается сам идентификатор блюда, и шаблон, используемый для этого,
как вы видите в этом примере,
/dishes/: и тогда вы указываете параметр здесь.
Чтобы сделать это легко для нас понять,
я назвал параметр DishID там.
Вы можете использовать любое имя параметра, которое вы выбрали, но, опять же,
использование значимого имени параметра упрощает понимание кода.
Таким образом, в этом примере
: Dishid означает, что если мы выдаем запрос на конечную точку,
скажем, /dishes/23,
то параметр DishID позволяет нам извлечь это число 23 так, что мы
можем работать на блюдо номер 23 в
функции, которая указана внутри этого метода здесь.
Таким образом, параметр,
сам параметр DishID может быть получен с помощью объекта запроса, на котором
поддерживается свойство params, а свойство
params поддерживает все параметры входящего запроса,
и DishID, в частности,
является одним из тех параметров запроса, которые можно получить доступ,
как показано в коде здесь.
Когда вы отправляете запрос PUT или POST от клиента на сервер,
вы часто вводите данные в тело сообщения, которое отправляется на сервер.
Теперь, что означает, что нам нужен метод
извлечения информации из тела сообщения.
Так вот где промежуточное программное обеспечение синтаксического анализа тела для Express очень полезно.
Таким образом, анализатор тела позволяет анализировать информацию из тела сообщения.
Чтобы использовать анализатор тела, как мы и ожидали,
мы установим модуль узла body-parser,
а затем запросим его в нашем приложении Express,
а затем укажите app.use (BodyParser).
И если тело содержит данные в формате JSON,
вы можете сказать BodyParser.json,
так что это означает, что это будет анализировать только данные, которые находятся в
формате JSON, которые заключены в тело этого сообщения запроса.
В частности, в упражнении
мы будем анализировать входящие данные, которые отправляются в виде строки JSON.
Парсер тела, как и следовало ожидать,
анализирует тело сообщения и заполняет свойство req.body.
Таким образом, по запросу
свойство body будет содержать все, что анализируется
из тела сообщения запроса парсером тела.
Если вы реализуете приложение Express,
которое поддерживает несколько конечных точек REST API,
то имеет смысл разделить код на
несколько модулей, а затем использовать их для создания общего приложения Express.
Так вот, где экспресс-роутер приходит нам на помощь.
Маршрутизатор Express определяет множество приложений Express,
и в рамках этого множества приложений Express
вы можете, например,
более подробно обращаться с одной конкретной конечной точкой REST API
или с одним конкретным шаблоном конечной точки REST API более подробно.
Так, например, мы можем определить DishRouter как Express.Router,
а затем DishRouter может обрабатывать конечные точки.
Поэтому, когда вы выражаете что-то как Express.Router,
он поддерживает конечную точку маршрута.
Одна из причин использования экспресс-маршрутизатора,
как вы понимаете,
заключается в том, что если мы используем стандартные
методы GET, PUT, POST и DELETE приложения,
для каждого из этих методов,
вам нужно явно указать конечные точки REST API.
Одно из преимуществ использования экспресс-маршрутизатора заключается в том, что если вы
говорите router.route, а затем укажете
конечную точку, эта конечная точка будет применяться ко всем методам, а все различные
методы GET, PUT, POST и DELETE, связанные с глаголами, могут быть
объединены в маршрут при определении кода для нашего приложения.
Мы рассмотрим более подробную информацию об этом в упражнении, которое следует за этой лекцией.
С этим быстрым пониманием того, как Express поддерживает конечную точку REST API,
давайте перейдем к упражнению, где мы построим
их поддержку для конечной точки /dishes REST API. В
рамках первого задания
вы будете продолжать расширять
это приложение Express для поддержки дополнительных конечных точек REST API,
включая /promotions и/leaders.
Если вы прошли предыдущие курсы по специализации,
вы сразу же начнете понимать, почему мы поддерживаем
все эти разные конечные точки REST API на другой стороне сервера.