[내보내번] Next.js docs - Dynamic API Routes

내보내번(내가 보려고 내가 번역한...) Next.js docs

2021년 4월 13일 기준 Next.js 공식 문서를 번역했다.

※ 영어 전공자도 해외 유학파도 아니기에 번역에는 의역, 오역, 구글 번역이 무수히 많을 수 있으며, 혼자 공식문서를 참조해가며 번역하다 보니 오타도 많을 수 있다. 정확한 내용은 공식문서를 직접 살펴보거나 다른 정보들을 더 찾아보는 것을 추천한다.

(하지만 댓글 피드백도 환영합니다😃 )

Next.js 공식문서 확인하기>>

API Routes: Dynamic API Routes | Next.js

---

API routes support dynamic routes, and follow the same file naming rules used for pages.
API 라우트는 동적 경로를 지원하고 페이지에서도 사용되었던 것과 같은 명명 규칙을 따른다. 

For example, the API route pages/api/post/[pid].js has the following code:
예를 들어, API 라우트 pages/api/post/[pid].js는 아래와 같은 코드를 포함한다: 

export default function handler(req, res) {
  const { pid } = req.query
  res.end(`Post: ${pid}`)
}

Now, a request to /api/post/abc will respond with the text: Post: abc.
이제 /api/post/abc에 대한 요청은 Post: abc라는 텍스트로 응답받는다. 

Index routes and Dynamic API routes 인덱스 라우트와 동적 API 라우트

A very common RESTful pattern is to set up routes like this:
라우트를 설정하기 위한 매우 보편적인 RESTful 패턴은 이와 같다:

• GET api/posts - gets a list of posts, probably paginated
• GET api/posts/12345 - gets post id 12345
• GET api/posts - 포스트 목록을 받는다. 아마도 페이지 매김이 되어있는
• GET api/posts/12345 - id가 12345인 포스트를 받는다

We can model this in two ways:
이것을 두 가지 방법으로 모델할 수 있다: 

• Option 1:
  • /api/posts.js
  • /api/posts/[postId].js
• Option 2:
  • /api/posts/index.js
  • /api/posts/[postId].js

Both are equivalent. A third option of only using /api/posts/[postId].js is not valid because Dynamic Routes (including Catch-all routes - see below) do not have an undefined state and GET api/posts will not match /api/posts/[postId].js under any circumstances.
두 가지 방법 모두 같다. 단 /api/posts/[postId].js만 사용하는 세 번째 옵션은 동적 경로(모든 라우트 포착(Catch-all routes)을 포함해서 - 하단 내용 참조)가 undefined 상태를 가질 수 없고 GET api/posts가 /api/posts/[postId].js 와는 어떤 경우에도 매치되지 않기 때문에 이 옵션은 유효하지 않다. 

Catch all API routes 모든 API 라우트 포착

API Routes can be extended to catch all paths by adding three dots (...) inside the brackets. For example:
API 라우트는 점 세 개(...)를 괄호 안에 추가함으로 모든 라우트를 포착하기 위해 확장될 수 있다. 예를 들면:

• pages/api/post/[...slug].js matches /api/post/a, but also /api/post/a/b, /api/post/a/b/c and so on.
• pages/api/post/[...slug].js 는 /api/post/a와 매치되지만 /api/post/a/b, /api/post/a/b/c 등의 경로와도 매치된다. 

노트: slug말고 [...param] 같이 다른 이름도 사용할 수 있다. 

Matched parameters will be sent as a query parameter (slug in the example) to the page, and it will always be an array, so, the path /api/post/a will have the following query object:
매치된 파라미터는 쿼리 파라미터(예시의 slug)로 페이지에 보내진다. 쿼리 파라미터는 항상 배열이며, /api/post/a 경로는 아래와 같은 쿼리 객체를 갖는다: 

{ "slug": ["a"] }

And in the case of /api/post/a/b, and any other matching path, new parameters will be added to the array, like so:
그리고 /api/post/a/b의 경우와 경로가 매치되는 다른 경우에도 새로운 파라미터들이 배열에 아래와 같이 추가된다:

{ "slug": ["a", "b"] }

An API route for pages/api/post/[...slug].js could look like this:
pages/api/post/[...slug].js를 위한 API 라우트는 아래와 같다: 

export default function handler(req, res) {
  const { slug } = req.query
  res.end(`Post: ${slug.join(', ')}`)
}

Now, a request to /api/post/a/b/c will respond with the text: Post: a, b, c.
이제 /api/post/a/b/c에 대한 요청은 `Post: a, b, c` 텍스트로 응답받을 것이다. 

Optional catch all API routes 선택적 API 라우트 포착

Catch all routes can be made optional by including the parameter in double brackets ([[...slug]]).
이중 대괄호 안에 파라미터를 포함하여 모든 라우트를 선택적으로 포착(catch)할 수 있다. ([[...slug]])

For example, pages/api/post/[[...slug]].js will match /api/post, /api/post/a, /api/post/a/b, and so on.
예를 들면, pages/api/post/[[...slug]].js는 /api/post, /api/post, /api/post/a, /api/post/a/b 등과도 매치된다. 

The main difference between catch all and optional catch all routes is that with optional, the route without the parameter is also matched (/api/post in the example above).
모든 라우트를 포착하는 것(Catch-all routes)과 모든 라우트를 선택적으로 포착하는 것의 주요 차이점은 선택적인 포착의 경우 파라미터가 없어도 매치가 된다는 것이다. (위의 예제에서 /api/post)

The query objects are as follows:
쿼리 객체는 다음과 같다: 

{ } // GET `/api/post` (empty object)
{ "slug": ["a"] } // `GET /api/post/a` (single-element array)
{ "slug": ["a", "b"] } // `GET /api/post/a/b` (multi-element array)

Caveats 주의사항

• Predefined API routes take precedence over dynamic API routes, and dynamic API routes over catch all API routes. Take a look at the following examples:
  미리 정의된 API 라우트는 동적 API 라우트보다 우선 순위가 높고 동적 API 라우트는 모든 API 라우트 포착보다 우선 순위가 높다. 아래의 예시들을 보자:
  
  • pages/api/post/create.js - Will match /api/post/create
    pages/api/post/create.js는 /api/post/create와 매치된다. 
  • pages/api/post/[pid].js - Will match /api/post/1, /api/post/abc, etc. But not /api/post/create
    pages/api/post/[pid].js는 /api/post/1, /api/post/abc 등과 매치 되지만 /api/post/create에는 매치되지 않는다.
  • pages/api/post/[...slug].js - Will match /api/post/1/2, /api/post/a/b/c, etc. But not /api/post/create, /api/post/abc
    pages/api/post/[...slug].js는 /api/post/1/2, /api/post/a/b/c 등과 매치 되지만 /api/post/create, /api/post/abc와는 매치되지 않는다.