[MUSIC]
Теперь, когда мы поняли REST API и выражаем поддержку
REST API, давайте перейдем к следующему упражнению.
Где мы рассмотрим, как мы будем развивать REST API,
используя поддержку, предоставленную express.
А также использование экспресс-маршрутизатора, что
позволяет нам организовать наш код таким образом, который более подходит,
когда вам нужно поддерживать большое количество конечных точек REST API.
Чтобы начать работу, продолжая работу с папкой node-express,
мы работаем над веб-сервером на основе экспресс.
В подсказке, давайте установим body-парсер,
поэтому для этого введите npm install body-parser —save.
И мы используем версию 1.18.3
body-parser в этом курсе здесь.
Теперь, как только мы установили body-парсер, затем войдем в наш код.
В index.js5
позвольте мне потребовать BodyParser, поэтому
мы скажем, const BodyParser
требует body-парсер.
И тогда всякий раз, когда вам нужно использовать промежуточное программное обеспечение,
вы скажете, app.use (BodyParser.json).
Таким образом, это позволяет анализировать тело сообщения запроса,
которое отформатировано в формате JSON.
Как только мы завершим это, давайте начнем
создавать поддержку REST API для конечной точки /dishes.
Использование
методов app.all, app.get, put, post и delete поддерживаются экспресс-.
Поэтому, чтобы сделать это, позвольте мне начать с выражения
app.all, и первые параметры,
которые принимает app.all, - это конечная точка.
Поэтому в этом случае я указываю конечную точку /dishes.
И тогда вторым параметром является функция обратного вызова,
req, res, далее, три параметра здесь.
И внутри этой функции обратного вызова мы будем обрабатывать входящий запрос.
Так что мы скажем, когда поступит запрос, для всех запросов.
Поэтому, когда мы говорим app.all, независимо от того, какой метод вызывается,
get, put, post или delete, для конечной точки /dishes REST API
этот код будет выполняться первым по умолчанию здесь.
Таким образом, мы скажем, res StatusCode 200, а
затем res.SetHeader и
скажем Content-Type текст.
Теперь мы отправим простой текст, вместо HTML-текста.
Этого должно быть достаточно для конечных точек REST API.
Позже мы отправим данные в виде JSON, как только
мы сможем получить данные из базы данных.
Так что придет в одном из последующих упражнений.
На данный момент мы просто отправим ответы в открытый текст обратно клиенту.
Теперь после этих двух промежуточное программное обеспечение здесь еще не завершено.
Таким образом, мы будем вызывать следующую функцию здесь, так что следующая, как вы видите, относится к этой следующей.
Поэтому, когда вы позвоните дальше, это означает, что он будет продолжать искать
дополнительные спецификации ниже здесь,
которые будут соответствовать этой конечной точке блюд.
Таким образом, это будет сделано для всех запросов, получить, положить, опубликовать и
удалить, на посуду, и это будет продолжаться до следующего.
Итак, предположим, что мы получим запрос
на блюда,
а это означает, что теперь, если мы получим запрос на блюда,
сначала это будет выполнено,
а затем req и res будут
переданы на этот второй вызов здесь.
Так что в этом случае мне больше не нужен следующий,
потому что я не собираюсь звонить дальше.
Я закончу обработку прямо в этом методе.
Поэтому, если мы изменим req или res внутри этого кода,
то при вызове следующего, этот модифицированный объект
будет передан в качестве параметра этому.
Поэтому, если вы выдали запрос get на блюда, так что это то, что будет
выполнено сразу после этого, так что следующее приведет к его передаче.
И тут, вы заметили, что мы изменили объект res здесь.
И модификация будет нести в качестве входного параметра этой функции здесь.
Так что внутри этой функции get мы можем сказать, например, на данный момент,
я просто собираюсь отправить обратно простое сообщение, скажем,
пошлю все блюда вам.
Позже, когда мы извлекаем информацию о блюдах из базы данных
после того, как мы узнаем о MongoDB, эта функция будет возвращать
данные JSON обратно клиенту, так как он находится в запросе get здесь.
Теперь в предыдущем курсе мы использовали JSON-сервер, и
сервер JSON уже предоставлял нам все это.
Теперь вы видите, как вы
построили реальный сервер, который будет обрабатывать входящий запрос.
А затем сгенерировать соответствующий ответ и
отправить его обратно вам в ответ на запрос, полученный со стороны клиента.
И вот где пользователь экспресс, как мы видим здесь, полезен.
Таким образом, мы справились получить,
давайте обрабатывать пост также на посуду здесь.
И снова параметры будут (req, res,
next), и эта функция, которая вызывается, будет здесь.
Теперь, когда получен запрос get, потому что здесь вы вызываете rest.end.
Таким образом, этот конец - это обработка запроса get и не вызывает ответ,
который будет отправлен обратно, или ответ, который будет отправлен обратно клиенту в этот момент.
Теперь, если вы получите почтовый запрос на блюда, опять же, весь этот код будет выполнен.
И затем, из-за этого следующего, это упадет в этот вызов функции здесь.
И тогда код здесь, будет выполнен, поэтому при получении сообщения Почтовый
запрос, поступающий с сервера, будет нести некоторую информацию
в теле сообщения в виде данных JSON.
Они увидят, какая форма данных JSON, когда мы
посмотрим позже, когда мы тестируем конечную точку с помощью post net.
Я покажу вам, что будет содержать тело сообщения о почтовом запросе.
Но в этот момент я собираюсь сделать,
я извлечу информацию из тела.
И поэтому, когда мы используем парсер тела, происходит то, что для
входящего запроса тело входящего запроса будет проанализировано, а
затем добавлено в объект req как req.body.
Таким образом, req.body даст вам доступ к всему, что находится внутри этого тела
сообщения.
Поэтому, когда я отправлю запрос,
я добавлю информацию в
тело запроса в виде строки JSON,
которая содержит имя и описание.
Поэтому я собираюсь извлечь эти две части информации, а
затем распечатать их, а затем отправить их обратно клиенту в ответном сообщении.
Так что я могу сказать, req.body.а затем имя.
И поэтому ожидание заключается в том, что когда клиент отправляет сообщение,
тело сообщения будет содержать строку JSON,
которая также будет содержать свойство name в строке JSON.
Итак, req.body.name plus, и
это то, где я буду включать
детали: + req.body.description.
Таким образом, независимо от того, что строка
JSON содержит в req.body, но строка JSON будет проанализирована
в объект JavaScript и добавлена в объект запроса в качестве тела свойства.
Объект JavaScript указывает на то, что
пришло в виде строки JSON в теле сообщения запроса.
Поэтому я могу разобрать свойство name, свойство description,
вы можете иметь свойство цены, свойство изображения и все это.
Поэтому, если вы взяли предыдущий курс, вы видели структуру
объекта блюда в виде строки JSON или объекта JavaScript там.
Итак, имя и описание звучит знакомо вам.
Так что именно то, что я использую здесь.
Сейчас я только извлекаю имя и описание из тела, а
затем отправляю его обратно клиенту в этом теле.
Поэтому я просто создаю это ответное сообщение здесь, используя информацию
из тела сообщения запроса, а затем отправляю его обратно клиенту.
Таким образом, я могу подтвердить, что сервер получает все, что я отправляю
в теле сообщения.
Так что это почтовый запрос.
Теперь, чтобы положить, позвольте мне просто скопировать это, а затем вставить его здесь.
А затем для надевания, что блюда конечной точки,
потому что он положить на блюда конечной точки не имеет смысла.
Сообщение означает, что вы размещаете новое блюдо на серверах.
Положить на конечную точку посуды не имеет смысла,
поэтому здесь, что я собираюсь сделать, я
собираюсь ответить обратно с помощью
операции PUT, не поддерживаемой /dishes.
Кроме того, я также, Включите код состояния 403.
403 означает, что их работа не поддерживается.
Поэтому, если вы оглянетесь на таблицу кодов ответа HTTP,
вы увидите соответствующий код 403, что он представляет там.
Так что это то, что я использую для публикации.
Для удаления я собираюсь скопировать
это, а для удаления я собираюсь,
Просто разобрать это, а затем мы скажем, Удаление всех блюд.
Поэтому, когда вы отправляете запрос на удаление на этой конечной точке /dishes.
Это означает, что
клиент хочет удалить всю информацию о блюдах на стороне сервера.
Теперь это опасная операция, поэтому
вы убедитесь, что вы не разрешаете партнерским пользователям делать это.
Поэтому позже, когда мы изучаем аутентификацию,
мы увидим, как мы можем проверить эту операцию только привилегированным пользователям.
Но опять же, как видите, это опасная операция, так что имейте в виду это.
Итак, теперь вы видите, что в конечной точке блюд мы получаем, ставим, размещаем
и удаляем поддержку.
Давайте также поддержим это на блюде/:Dishid конечной точки.
Поэтому я собираюсь скопировать методы get, put, post и delete отсюда,
а затем вызывает все их также, чтобы поддерживаться на
блюде/:dishid.
Так что это для получения, и мы копируем это и
публикуем, помещаем и удаляем.
Как мы справимся с каждым из них?
Поэтому для получения, если я получаю запрос на тарелки/Dishid,
то, что я хотел бы сделать, это извлечь этот параметр, а
затем отправить его обратно в запрос, в ответном сообщении.
Так что мы скажем, мы отправим,
Детали блюда.
Теперь какое блюдо?
Эта информация находится в параметре.
Таким образом, это значение параметра может получить из
req.params.dishid.
Таким образом, этот diShid, как вы видите, имя, которое вы используете здесь, должно соответствовать этому значению здесь.
Поэтому, если вы просто видите идентификатор здесь,
это также должно соответствовать данному SID здесь.
Таким образом, само имя ничего не значит, за исключением того, что это имя параметра и
это должно совпадать друг с другом, так что вы можете получить информацию правильно.
Так что скажем, пришлите параметры тарелки DishID, а
потом мы вам скажем.
Таким образом, мы знаем, что сервер получает параметр блюда..
Так что если я скажу /dishes/23 там несколько ответов
присылают детали блюда 23 вам и так далее.
Таким образом, мы увидим, как это работает, когда мы используем пост для тестирования этого сервера.
Теперь на пост.
Для сообщения этот метод не будет поддерживаться,
поэтому я просто собираюсь скопировать эту часть.
не имеет смысла делать сообщение на определенном идентификаторе блюда,
потому что вы не пытаетесь добавить новое блюдо.
Но вы хотите изменить, и модификация выполняется с помощью операции ввода.
Таким образом, скажем, операция POST не поддерживается на /dishes.
И тогда я собираюсь добавить в.
Рек.парам.Дишид.
Таким образом, это отправит обратно сообщение, не поддерживаемое на
блюде/23 в ответном сообщении.
Теперь, для PUT, для PUT, мы скажем,
res.end и скажем Уилл, обновить блюдо.
Рек.парам.Дишид.
Вернее, мы сделаем это таким образом.
Сначала я напишу, поэтому
res.write можно использовать для добавления строки в ответное сообщение.
Так что скажем, обновление блюда.
И мы скажем req.params.dishid.
И поскольку это операция PUT, и если тело содержит строку JSON,
которая содержит детали блюда,
я могу извлечь строку JSON, потому что мы используем анализатор тела.
Так что мы скажем, будет
обновлять блюдо:.
Какое блюдо?
req.body.name.
Плюс.
С подробностями,
req.body.description.
Теперь, когда мы обновляем блюдо, я хочу добавить, Новая строка там.
Так что я скажу «/n» там.
Поэтому, когда вы делаете PUT, вы отправляете обратно информацию о том, какой идентификатор блюда вы
обновляете, а также детали, которые вы обновляете.
Имя и описание,
которое должно быть в теле сообщения PUT.
Для удаления, Это будет сказать Удаление блюдо, и req.params.dishid.
И поэтому для удаления, это операция, которая будет выполнена.
Таким образом, вы видите, что теперь у нас есть
операции get, put, post и delete на диске/dishid, конечной точке, а
также операции get, put, post на /dishes, конечной точке.
Итак, давайте сохраним изменения.
И снова запустите наш сервер.
Запустите сервер, сказав npm start.
Давайте теперь перейдем к почтальну и отправим несколько запросов на этот сервер и
посмотрим, что он возвращает.
Позвольте мне сначала получить доступ к локальному хосту 3000 и посмотреть, что он возвращает.
Поэтому, когда вы отправляете запрос на получение локального хоста 3000,
он все еще возвращает HTML-страницу запуска индекса,
потому что статическая обработка файлов все еще на месте.
Теперь позвольте мне отправить запрос на localhost: 3000/блюда, и это,
как вы ожидаете, отправит обратно ответ, говорящий, что мы вышлем все блюда вам.
Теперь давайте отправим запрос POST на локальный хост: 3000/блюда.
Таким образом, здесь вы можете изменить различные методы, которые вы хотите выполнить.
Но когда вы отправляете сообщение,
вы хотите включить некоторые детали в тело сообщения, потому что
кто-то ожидает, что вы отправите информацию в тело сообщения.
Поэтому нажмите на тело здесь и нажмите на сырую здесь.
И затем, для текста, вы выбираете это в JSON, поэтому
используйте приложение JSON.
Таким образом, тип содержимого будет приложением/JSON
в запросе, который вы отправляете.
Поэтому, поскольку это объект JSON, поэтому
в фигурных скобках я скажу имя.
Я просто напечатаю тест
и описание.
Некоторая стандартная информация здесь, поэтому вы видите, что это строка JSON, которая
содержит два свойства, имя и описание и соответствующие значения.
Итак, давайте отправим почтовый запрос на сервер.
При отправке почтового запроса на сервер, как вы видите,
в ответе говорится, что добавит блюдо: тест недели подробности: описание.
Таким образом, как вы можете видеть, две части информации извлекаются
из тела этого JSON запрошенного [INAUDIBLE], а затем включаются в ответ.
Давайте отправим запрос на посуду.
Когда вы отправляете запрос put в блюда, как вы видите,
он говорит, что операция PUT не поддерживается /fishes, и посмотрите на статус здесь.
Здесь написано «Статус: 403 Запрещено».
Таким образом, эта операция не разрешена на этой конечной точке.
Давайте сделаем операцию DELETE на посуду.
Когда вы DELETE операции на посуду,
то вы заметите, что он говорит удаление всех блюд.
Так вот ответ, который вы получите.
Таким образом, вы видите, что get post, put и
delete в конечной точке /dishes работает так, как вы ожидаете.
Теперь давайте займемся посудой /23.
Итак, 23 вот параметр,
идентификатор блюда, которое вы хотите получить.
Поэтому, когда вы отправляете запрос на то, что сервер
ответит, вышлет вам детали блюда: 23.
Таким образом, вы видите, что параметр был извлечен из сообщения запроса, а
затем включен в ответное сообщение.
Давайте сделаем сообщение об этом.
И, как вы знаете, POST запрещен на этой конечной точке, и
поэтому вы получаете статус 403 Запрещен на этом.
Давайте сделаем операцию PUT на этом.
Поэтому для операции PUT вы заметили, что тело все еще содержит это.
Поэтому в POST, когда вы вводите значение здесь,
оно будет сохранено и может быть включено в другие запросы, которые вы отправляете.
Поэтому, когда вы отправляете запрос PUT на конечную точку, тарелки/23.
Итак, вы заметили, что здесь написано обновление блюда, 23.
Обновите блюдо, название блюда,
с подробностями, описание блюда здесь.
И затем, давайте сделаем операцию удаления на этой конечной точке
, а затем он говорит: d удаление тарелки: 23.
Таким образом, все эти конечные точки поддерживаются, как вы видите в этом примере.
Таким образом, мы выполнили операции PUT, POSRT и удаления как в конечной точке
/dishes, так и в конечной точке идентификатора блюда.
Итак, вы видите, как мы реализовали поддержку конечных точек REST API для
одного набора конечных точек REST API.
Теперь, с этим, мы завершаем первую часть этого упражнения.
Итак, здесь мы видели, как мы можем использовать express для построения и
реализации конечной точки REST API для блюд.
Теперь это хорошее время для
вас сделать git фиксацию с сообщением Express Simple REST.
В соответствии с терминалом я начну, Сервер.
Убедитесь, что три элемента были изменены.
Итак, git add, git commit -m,
Express Simple REST и проверьте набор.
Таким образом, как вы можете видеть, с помощью Express вы можете легко реализовать поддержку REST API.
И, как вы можете видеть из этого списка, вы создаете
методы приложения get, PUT, POST и удаления для всех конечных точек REST API, подобных этому.
Теперь представьте, что у вас есть тысяча конечных точек REST API,
и вам нужно построить что-то вроде этого.
Ваш файл index.js будет взорваться с таким количеством различных конечных точек REST API.
И каждый из них обрабатывается с помощью собственного app.get,
app.put, app.delete и app.post.
Теперь Wxpress поддерживает способ разделения этой работы на несколько,
много приложений Express,
которые затем могут быть объединены вместе, чтобы сформировать общее, Express приложение.
Здесь мы будем использовать Express Router,
чтобы иметь возможность построить мини-Express приложение.
И затем, внутри файла Express Router,
мы будем поддерживать конечную точку REST API для одной группы частей REST API.
Так, например, для посуды и посуды DisHID,
все они могут поддерживаться в одном файле.
Аналогичным образом, в задании вы будете поддерживать
конечную точку REST API, называемую промо-акции и промо-акции.
А затем вы поддержите другой REST API и
для лидеров и /лидеров: LeaderID.
Таким образом, каждая из этих групп может быть реализована отдельно, как и многие
Express приложения, использующие Express Router.
Вот что я проиллюстрирую вам для
конечной точки блюд в следующей части этого упражнения.
Поэтому для этого мы понимаем, что если мы поместим все файлы в одну папку,
то опять же ваша структура папок будет выглядеть грязной.
Поэтому мое предпочтение - создать папку здесь с именами маршрутов.
И эта папка маршрутов будет содержать все маршрутизаторы, которые я собираюсь
создать с помощью экспресс-маршрутизатора.
Поэтому в папке маршрутов я собираюсь создать новый файл под названием
dishRouter.js.
И этот файл dishRouter.js будет содержать
реализацию обработки конечной точки REST API для
/bishes и/dishes:dishid конечных точек.
Теперь как мы используем Express Router?
Посмотрим, как мы можем использовать его.
Теперь Express Router поставляется вместе с Express, поэтому нам не нужно устанавливать
еще один модуль Node.
Вместо этого мы можем работать с Express, который мы уже установили.
Поэтому для этого в этой подсказке введите const express
= require ('express');.
Поэтому обратите внимание, что, поскольку это мини-приложение,
мы все еще требуем экспресс даже в этом файле dishRouter.js.
И из ваших знаний о модулях Node, как только вы определяете новый файл,
который становится его собственным модулем Node.
И этот модуль Node может быть импортирован в index.js.
Таким образом, вы видите связь уже между тем, как мы можем реструктурировать наше
приложение в несколько файлов с помощью модулей Node.
Таким образом, мы установим требование Express, тогда мы скажем, const
BodyParser требует («body-parser»).
Таким образом, мы уже установили BodyParser на предыдущих этапах упражнения,
поэтому мы можем использовать это.
Теперь, чтобы использовать Express маршрутизатор,
позвольте мне объявить const DishRouter = Express.r.
И на express, он поддерживает этот интерфейс маршрутизатора, так что мы просто
скажем Express.Router и это объявит DishRouter как Express маршрутизатор.
Поэтому во многих приложениях Express
понимание здесь я могу обрабатывать этот код, связанный с DishRouter здесь.
Поэтому, как только я объявляю об этом в Express маршрутизаторе, я могу сказать DishRouter.
И затем на DishRouter он поддерживает метод route method,
который может принимать конечную точку в качестве параметра.
Поэтому я бы просто объявил эту конечную точку a /.
А теперь вам интересно, разве это не посуда?
Вы скоро увидите, что мне нужно смонтировать этот
Express маршрутизатор в моем файле index.js.
Поэтому в моем файле index.js я монтирую этот экспресс-маршрутизатор в конечной точке /dishes.
Монтаж экспресс-маршрутизатора, опять же,
еще одна концепция, которую я хочу, чтобы вы поняли.
Опять же, я проиллюстрирую это вам через короткое время.
Теперь DishRouter.Route означает, что, используя этот подход,
мы объявляем конечную точку в одном месте. Таким
образом, вы можете цепочки все получить, PUT, POST,
удалить методы уже делают этот маршрутизатор блюдо.
Теперь, когда вы смотрите на index.js, посмотрите, как мы это имплицировали.
Таким образом, у нас есть app.all, а затем /dishes, app.get/dishes и/dishes.
Теперь, если вы допустили ошибку, и их инструкция app.post
/dishes вместо этого, если вы просто введете /dish, то что происходит?
Операция POST не будет поддерживаться на блюдах, но
будет поддерживаться на конечной точке /dish.
Чтобы избежать этой проблемы, экспресс-маршрутизатор поддерживает эту конечную точку маршрута.
В конечной точке маршрута
просто укажите конечную точку, в которой будет работать этот маршрутизатор.
И затем, метод удаления части get put, это просто приковано к этому.
Таким образом, это будет одна группа реализаций методов все вместе.
Поэтому они используют экспресс-маршрутизатор.
Таким образом, он поставляется с парой очень полезной
поддержки, чтобы убедиться, что ваша реализация верна.
Так что теперь, когда мы собираемся сделать это как маршрутизатор посуды,
то, что я собираюсь сделать, я собираюсь удалить эту вещь отсюда.
Теперь, что блюда IDN точка, я собираюсь оставить это
вам в качестве упражнения в вашем первом задании
, но конечная точка блюда, я собираюсь вырезать это, вплоть до всех.
Я собираюсь вырезать это из index.js5 и
переместить это в DishRouter здесь.
Теперь, когда я перемещаю это в DishRouter, мне больше не нужно это app.all.
Я просто цепь это в маршрут, поэтому я просто скажу .all, а
затем мне больше не нужно это определение конечной точки там.
Вот оно. Так что
будет сказано «все», а потом мы скажем «req», «res», «следующий».
И это, все работает на этой конкретной конечной точке,
уже указанной здесь.
Теперь, не только это, мы можем цепочку оставшихся методов.
Вот почему вы видите, что я удалил точку с запятой отсюда.
Я собираюсь удалить это приложение, а затем прикрепить его к этому.
Таким образом, получает также изменяется в маршруте, а затем я могу удалить
эту часть, обработка останется точно такой же, как и раньше.
Таким образом, я удалю приложение там.
И снова удалите это из поста.
И то же самое.
Для пута, и
для удаления, то же самое.
Обратите внимание, что здесь, здесь или
здесь нет точек с запятой, но последний, удаление, будет иметь точку с запятой.
Таким образом, эта группа представляет собой одну единицу, реализованную с помощью
dish маршрутизатора на этом конкретном маршрутизаторе, и все они соединены друг с другом.
И также, конечно, с удалением, мне нужно удалить эту конечную точку.
Вот, видишь ли, чистая структура кода здесь.
Таким образом, по существу, заканчивается реализацией DishRouter, правильно,
помните, что этот DishRouter определен внутри файла dishRouter.js.
Теперь мне нужно экспортировать это из этого модуля узла.
Поэтому, чтобы экспортировать это, я перейду вниз здесь, и
я скажу module.exports и
скажу, DishRouter.
Вот оно.
Итак, теперь мой DishRouter экспортирует все, что мне нужно.
Теперь ты смотришь на это и говоришь, что насчет блюда Колон.
Это будет частью вашего первого задания.
Мало того, что вы будете внедрять для
двух дополнительных конечных точек REST API, рекламных акций и лидеров.
Но это уже показывает вам структуру того,
как выглядит реализация экспресс-маршрутизаторов поддержки res API.
Так что это для DishRouter.Route.
И последнее, прежде чем я забуду,
мы должны сказать Dishrouter.use (Bodyparser.json ()).
Теперь, как только вы завершите реализацию DishRouter,
мы можем перейти к файлу index.js.
Так как этот DishRouter является еще одним узловым модулем, тем не менее тонким узлом
Поэтому нам нужно импортировать это в наше приложение.
Так что прямо здесь, я собираюсь импортировать const
DishRouter равен требованию.
Теперь, поскольку это файловый модуль узла,
я скажу. /Маршруты/Посудомоечная машина.
И как только я объявил их там, тогда я вхожу в код здесь.
И прямо там, я говорю app.use.
И я монтирую маршрутизатор в конечной точке.
Итак, как мне смонтировать маршрутизатор?
Первый параметр здесь, я буду указывать слэш блюда.
И второй параметр, укажите DishRouter.
И вот оно.
Так что это означает, что в моем экспресс-приложении
любой запрос, приходящий к этой конечной точке косой черты, будет обрабатываться DishRouter,
и это будет сделано с помощью кода, который присутствует здесь,
потому что мы сказали маршрут DishRouter, и поэтому обратите внимание, что это говорит косая черта,
так что это означает, что монтируется в конечной точке слэша.
Вот почему все, что приходит через косую посуду, будет отправлено на это и
будет обрабатываться этим.
Большой намек для вас, чтобы подумать о том, как вы бы реализовали
конечную точку идентификатора блюда толстой кишки.
Вы по-прежнему будете использовать тот же файл dishRouter.js, чтобы также реализовать поддержку
этого, /dishes/:dishid конечной точки.
Это еще один большой намек для тебя, хорошо.
С этими изменениями, давайте сохраним изменения, которые мы сделали
в нашем приложении, а затем перезапустите наш сервер, а
затем посмотрим, как наш сервер будет делать свою работу.
Перейдя к терминалу, позвольте мне перезапустить этот сервер, введя npm start.
И как только сервер будет запущен, я пойду к почтальонам и
отправлю запросы от почтальона на этот сервер.
Отправляясь в почтальон, теперь я знаю, что мой сервер поддерживает только
конечную точку блюда, я реализовал часть блюда ID его.
Поэтому позвольте мне отправить запрос на местные блюда хоста, и
вы увидите, что он работает точно так же, как и раньше.
Теперь, если вы сделали предыдущий запрос в сообщении, вы можете просто нажать на это, а
затем повторно отправить этот запрос.
Операция Put не работает, после операции, Работает, как вы видите там.
И тогда давайте вызовем операцию удаления на тарелке.
И он говорит, что удаление всех блюд, как ожидалось.
Таким образом, это реализация поддержки остальных API с использованием экспресс-маршрутизатора.
Этим мы завершаем вторую половину этого упражнения.
Это подходящее время для вас сделать комментарий с помощью экспресс-маршрутизатора сообщений.
Теперь, когда мы завершили это упражнение, где мы увидели, как Express может
быть использован для поддержки реализации поддержки конечных точек Res API на нашем сервере,
а также использования Express маршрутизатора,
пришло время перейти к первому заданию, которое следует за этим уроком.
[ МУЗЫКА]