form 태그에는 action 속성이 있으며, 해당 속성에 http 요청을 보낼 URL 경로를 입력하고, method로 getpostpatch 등 메서드를 입력하면 폼 정보 입력 시 곧바로 요청을 보낼 수 있다.
POST 요청을 예를 들면, POST 할 데이터는 요청의 body에 담겨서 전달되는데, form 태그의 action 요청은 브라우저의 기본 데이터 전송 타입인 application/x-www-form-urlencoded 타입이다(URL 뒤에 ?{key}={value} 형태로 전달할 데이터를 체이닝하는 방식으로 사용된다).
application/x-www-form-urlencoded 타입으로 전달된 데이터를 Express 서버에서 받아주려면 express.urlencoded({ extended: true })로 미들웨어 설정이 필요하다. 해당 미들웨어를 app.use(express.urlencoded({ extended: true })) 형태로 설정해서 라우트 경로에 상관 없이 접근하는 모든 서버 경로에서 적용되도록 해주면 요청의 body에 담긴 application/x-www-form-urlencoded 형식의 데이터를 파싱해서 사용할 수 있다.
같은 맥락에서, 클라이언트에서 요청이 올 때 body에 application/json 타입으로 데이터가 온다면 app.use(express.json())으로 설정해주면 요청에 담겨 온 데이터를 서버에서 활용할 수 있다.
요청은 기본적으로 app.post({경로}, (req, res) => req.body)로 받을 수 있다. req 객체에는 body라는 객체가 있으며, app.use로 설정한 미들웨어들에서 분석해준 데이터가 req.body로 들어오게 된다.
미들 웨어(Middle ware)란, 클라이언트의 요청과 서버의 응답 사이에서 어떠한 동작들을 처리해주는 함수들을 의미하는 것 같다. 간단하게 찾아봐서 100% 이해가 되진 않았지만, app.get({경로}, {콜백 함수}) 형태로 사용됐을 때 {콜백 함수}에 해당하는 부분이 미들 웨어인 것 같다.
미들 웨어는 요청을 분석하고, 필요한 데이터를 파싱하고, 데이터를 가공 및 처리해서, 응답을 클라이언트로 전달해주는 과정에서 필요한 모든 처리에 활용된다. 미들 웨어는 사용자가 직접 커스텀한 함수일 수도 있고, Express에서 제공되는 함수일 수도 있다.
express.urlencoded나 express.json은 Express에서 기본 제공해주고, 요청의 body에 담긴 데이터들을 파싱해주는 역할을 하는 미들 웨어다.
REST API는 strict한 규칙이라기보단, 좋은 API를 설계하기 위한 방법론에 가깝다. REST API를 지키지 않더라도 http 요청을 주고받는 게 불가능하진 않지만, 그래도 가급적 지켜주는 게 구조적으로 더 좋다.
REST API는 '무상태성'이라는 특징이 있고, 동작을 method로, 자원(Resource)을 URL 경로로 표현한다.
REST API에는 여러 규칙들이 있는데, 웹 통신에서 중요한 내용인 만큼 다음에 시간을 잡고 제대로 공부해 봐야겠다.
comments 경로로 GET, POST 요청이 보내질 수 있고, POST 요청이 된 이후에 곧바로 GET으로 리다이렉트를 하고 싶다면 res.redirect 메서드를 사용한다.
res.redirect에 인자로 경로를 넣어주면 먼저 상태 코드 302를 보내준다. 300번 대 상태 코드는 리다이렉트에 대한 코드들이고, 브라우저는 302번 상태 코드를 확인하면 리다이렉트를 위한 경로를 확인해 다시 한번 http 요청을 보내준다. 즉, res.redirect로 리다이렉트를 처리할 시 응답은 총 두 번(status: 302라는 응답과, GET /comments의 응답)을 내려준다.
서버 사이드에서 사용자의 이벤트에 따라 화면을 전환하려면 별도의 html 파일을 만들어주고 새롭게 리렌더링 해주면 된다.
그래서, Express로 만드는 웹 페이지에서도 라우트 경로에 따라 html 페이지(ejs 페이지)를 만들고, 이벤트에 따라 a 태그를 이용해서 href에 이동할 ejs 파일의 경로를 넣어주면 된다.
데이터베이스에서 값을 가져올 땐 아마도 별도의 id가 보통 있을 것이지만, 상황에 따라 별도의 id를 직접 생성해서 사용해야 하는 경우도 존재한다. 그럴 땐 npm에서 제공되는 uuid를 사용할 수 있다. uuid를 사용하면 실행할 때마다 다른 값과 절대 중복되지 않는 고유한 문자열을 받아올 수 있다.
form 태그의 입력 값으로 patch 요청을 보내고 싶을 수 있다. 하지만, form 태그는 기본적으로 get과 post 요청만 지원하며, patch, put, delete 등의 요청은 지원하지 않는다.
사실 일반적인 클라이언트와의 통신에서는 http method를 patch로 해서 요청을 잘 보내줄 수 있기 때문에 그렇게 일반적인 상황은 아닌 것 같긴 하다. 하지만, 일부 상황에선 patchputdelete 등의 메서드를 사용할 수 없는 경우가 분명 존재할 수 있다.
이럴 경우 사용할 수 있는 Express의 미들 웨어가 method-override이다. npm i method-override로 설치할 수 있고, const methodOverride = require('method-override')로 불러와 사용할 수 있다.
require로 불러온 method-override 패키지는 함수를 반환한다. 함수에 특정 파라미터를 전달하면 해당 파라미터의 값으로 온 메서드를 실제 메서드로 인지해준다.
method-override를 사용해 메서드를 오버라이딩 하는 방법은 여러가지다. 그 중 한 방법은 URL의 쿼리 파라미터를 사용하는 방법이다.
예를 들어, app.use(methodOverride('_mehtod'))로 설정한 다음 /comments/:id?_method=PATCH라고 경로를 잡아주면 실제 메서드를 post로 해서 요청을 보냈더라도 서버에선 patch 메서드로 인지하고 app.patch('/comments/:id', {콜백 함수})를 호출해준다.
_method라고 해서 앞에 언더스코어를 넣어준 이유는, methodOverride 목적이 아닌 경우에도 method라는 쿼리 파라미터는 충분히 사용 가능하기 때문이다. 파라미터 값의 중복을 피하기 위해 _method라는 식으로 사용할 수 있다.