소개

이전에 저는 Express-Generator를 시작하는 방법에 대한 블로그를 작성했습니다. Express에서 설정하려는 경우 . 이 블로그에서 우리는 지난 Express 블로그를 피기백하고 라우팅이 어떻게 작동하는지 이해하게 될 것입니다.

자원

The Postman App 을 다운로드하는 것이 좋습니다. 테스트 양식을 작성하고 데이터베이스를 가짜 데이터로 채우지 않고 HTTP 요청을 테스트하는 데 정말 좋습니다. (예: [email protected] + somepassword1234 ) 가장 좋은 점은 모든 라이브러리/프레임워크에서 작동한다는 것입니다. 논리를 처리하는 기술에 대해 완전히 언어에 구애받지 않는 동안 이러한 HTTP 요청을 테스트합니다.

HTTP 요청

이전에 요청을 처리한 적이 있다면 GET , POST , PUT 및 DELETE 와 같은 기본 요청에 익숙할 것입니다.


HTTP 요청
예시
의미


가져 오기
/게시물
사용자의 게시물을 GET 표시하거나 표시하기 위한 것입니다.

게시하다
/게시물
데이터베이스에 대한 정보POST를 의미합니다. 이 경우 새 게시물 작성

놓다
/posts/:id/편집PUT 또는 업데이트 정보를 의미합니다. 이 경우 데이터베이스의 ID로 사용자의 게시물을 업데이트합니다.

삭제
/게시물/:아이디
데이터베이스의 정보DELETE를 의미합니다. 이 경우 사용자의 게시물을 삭제합니다.


총 7개의 HTTP 요청, GET , POST , PUT , HEAD , DELETE , PATCH 및 OPTIONS 가 있습니다. 우리는 그 중 4개만 다룰 것입니다.

경로

경로 아래에 파일posts.js을 만듭니다. 다음 코드로 채우십시오.

const express = require('express');
const router = express.Router();

/* GET posts index /posts */
router.get('/', (req, res, next) => {
  res.send('INDEX /posts');
});

/* GET posts new /posts/new */
router.get('/new', (req, res, next) => {
  res.send('NEW /posts/new');
});

/* POST posts create /posts */
router.post('/', (req, res, next) => {
  res.send('CREATE /posts');
});

/* GET posts show /posts/:id */
router.get('/:id', (req, res, next) => {
  res.send('SHOW /posts/:id');
});

/* GET posts edit /posts/:id/edit */
router.get('/:id/edit', (req, res, next) => {
  res.send('EDIT /posts/:id/edit');
});

/* PUT posts update /posts/:id */
router.put('/:id', (req, res, next) => {
  res.send('UPDATE /posts/:id');
});

/* DELETE posts destroy /posts/:id */
router.delete('/:id', (req, res, next) => {
  res.send('DELETE /posts/:id');
});


module.exports = router;

이제 app.js 내부에서 5번과 11번 줄 사이에 다음 줄을 적용합니다.

const posts = require('./routes/posts');

그리고 21행과 27행 사이의 이 행은 다음과 같습니다.

app.use('/posts', posts);

여기서 The Postman App이 유용할 것입니다. 에서 온 경우 터미널에 nodemon를 입력하여 서버를 시작할 수 있습니다. The Postman App 을 사용하여 각 경로가 올바르게 작동하는지 테스트하기 시작할 수 있습니다. 각 라우트의 응답은 각 라우트/HTTP 요청이 자체 응답을 전달하는 res.send('string-information-here') 내부에 있는 것과 정확히 같습니다.

이것이 모든 경로 파일에 대한 올바른 설정입니까?

처음에는 그렇게 생각할 수도 있지만 데이터베이스의 모든 항목에 반드시 특정 작업이 필요한 것은 아니라는 점을 이해하는 것이 중요합니다. 한 가지 예는 리뷰를 작성할 때입니다. 검토 양식을 위해 전체 경로를 만드는 것이 합리적입니까?

보고 있는 사용자의 게시물과 동일한 경로에 해당 양식을 첨부하는 것이 더 합리적이지 않습니까? 가지고 있는 애플리케이션 유형에 따라 사용자가 자신의 리뷰를 삭제하는 것을 원하지 않을 수도 있습니다(어떤 이유로든). 요점은 설정한 라우팅 유형이 애플리케이션의 원하는 동작에 크게 의존한다는 것입니다. 자신의 코드를 작성하고 좁은 사용 사례를 연습하는 것보다 이러한 개념을 더 잘 확고히 할 수 있는 정보는 여기에 없습니다.

결론

RESTful 라우팅은 MVC 프레임워크와 관련하여 거의 동일한 패턴을 따릅니다. Ruby on Rails 배경에서 나온 Express도 예외는 아닌 것 같습니다. MVC 아키텍처를 이해하는 것은 양도 가능한 기술로 가장 중요합니다. 나는 가까운 장래에 Express에 대한 더 많은 블로그를 계속 쓸 것이기 때문에 계속 지켜봐 주십시오. 😉

질문이 있으시면 댓글을 남겨주세요! 기꺼이 답변해 드리겠습니다.

나를 따르라!

Github/MatthewPalmer9