node>서버와 유저가 통신하는 법 / RESTful API

글작성기능을 만들어볼건데 

그 전에 개념설명을 하나하고 지나가야합니다.

 

 

1. 서버가 뭐냐면

 

강의 맨 처음에 쉽게 설명했는데

서버는 그냥 요청이 들어오면 그걸 처리해주는 간단한 프로그램입니다.

누가 웹툰달라고 하면 웹툰보내주고

DB데이터 달라고하면 DB데이터 보내주는 프로그램일 뿐임

반대로 DB에 데이터좀 저장해달라고 하면 데이터 저장해주는 것도 가능합니다.

아무튼 서버는 누가 뭔가를 요청하면 그걸 처리해주는 프로그램일 뿐인데

 

 

 

 

2. 예의바르게 요청해야함

 

유저 마음대로 대충 서버에게 요청하면 서버는 데이터를 보내주지 않습니다.

유저가 서버에게 뭔가 요청하려면 1. method 2. URL을 정확히 적어서 보내야합니다 

 

 

 

method는 이런 것들이 있는데 이 중에서 마음에 드는거 하나 고르면 됩니다.

GET은 서버에게 데이터를 달라고할 때 

POST는 서버에게 데이터를 보내고싶을 때

UPDATE, PUT은 서버에게 DB 수정요청같은걸 할 때

DELETE는 서버에게 DB 삭제요청같은걸 할 때  

많이 사용합니다. 

 

요청할 URL도 잘 기입하면 됩니다. URL을 엔드포인트라고 부르기도합니다. 

그래서 method, URL 을 잘 기입해야 서버가 진짜로 요청을 처리해줍니다. 

정확히는 요청을 HTTP 요청,

method를 HTTP method 라고 부릅니다.

 

 

 

 

3. 유저는 서버가 미리 정의해놓은 method와 URL 조합을 정확히 입력해야 

 

한식당에서 파스타를 달라고 할 수는 없기 때문에

유저는 당연히 서버에 미리 정의해놓은 method와 URL 조합을 입력해서 요청해야합니다. 

지금까지 서버 파일에 이런 식으로 작성하지 않았습니까 

 

 

app.get('/list', (요청, 응답) => {
  어쩌구~
})

▲ 이게 실은 어떤 유저가 /list 로 GET요청하면 이런거 보내주세요~ 라고 코드짠겁니다.

이런 코드를 미리 적어놔야 유저가 /list로 GET요청할 수 있는 것임 

 

서버에 미리 만들어놓은 method와 URL을 멋있는 말로 서버의 API라고 합니다.

API는 뭐 어려운 표현같지만 그냥 프로그램 사용법이라고 이해하면 됩니다. 

app.get( ) 이것들은 서버라는 프로그램 사용법 아닙니까 

그래서 서버 API라고 부릅니다.

 

 

참고로 .get을 .post로 바꾸면 "어떤 유저가 /list로 POST요청하면~" 이라는 뜻

.get을 .delete로 바꾸면 "어떤 유저가 /list로 DELETE 요청하면~" 이라는 뜻입니다. 

 

 

 

 

 

4. 유저는 GET요청을 어떻게 함?

 

유저가 서버에게 요청을 보낸다고 했는데 

근데 요청을 대체 어떻게하면 보낼 수 있는거죠? 

 

실은 누구나 알고 있는 GET요청 방법이 하나 있는데 

여기 웹브라우저 주소창에다가 URL을 때려박으면 거기로 GET요청을 날려줍니다.

GET요청 방법 중 가장 쉬운 방법임 

 

 

 

app.get('/list', (요청, 응답) => {
  어쩌구~
})

▲ 그럼 아까 서버기능 이렇게 만들어놨으면 

브라우저 주소창에 /list 라고 입력만 하면 요 서버기능을 동작시킬 수 있는겁니다. 

웹이 이런식으로 동작함 

 

유저가 POST 요청은 어떻게 하냐고요?

그건 html <form> 태그를 쓰면 되는데 다음에 알아봅시다. 

 

 

 

 

 

 

5. 유저가 서버파일을 볼 수 있는것도 아닌데 어떤 url과 메소드를 사용해야하는지 어떻게 알죠?

 

서버만든 사람에게 "서버기능 뭐 만들어놨냐"고 물어봐야지 뭐 어쩌겠습니까 

그러면 개발자가 귀찮아지기 때문에

웹페이지에다가 URL 링크같은걸 숨겨놓는 식으로 개발합니다.

 

이런 버튼 누르면 /어쩌구로 GET요청되게 만들고 

저런 버튼 누르면 /어쩌구로 POST요청되게 만들고 

그런 식으로 html을 꾸며놓으면 됩니다. 

그래서 유저들은 get요청 post요청 url 이런 개념 하나도 몰라도

웹사이트랑 웹서버랑 통신해서 이거저거 데이터를 받아볼 수 있습니다. 

 

 

 

이런거 큰 그림 설명하는이유가 뭐냐면

큰 그림, 동작원리 같은거 잘 알아야 직접 코드를 짤 수 있습니다. 

배운 내용 그대로만 코드짜는건 GPT가 더 잘함 

 

 

 

 

 

API를 그래서 앞으로 많이 만들건데

 

RESTful API 라고 부르는 개념도 있는데 알아두면 좋으니까 알아보도록 합시다. 

REST는 어떤 잡배 아저씨가 졸업논문으로 쓴 '좋은 API 만드는 법'을 의미합니다.

6가지 원칙이 있는데 

 

1. Uniform Interface 

- 여러 URL과 method는 일관성이 있어야합니다.

- 하나의 URL로는 하나의 데이터를 가져오게 디자인하는게 좋고 

- 간결하고 예측가능하게 URL과 method를 만드는게 좋습니다. 

 

2. Client-server 역할 구분 

유저에게 서버역할을 맡기거나 DB를 직접 입출력하게 시키면 안좋습니다. 

 

3. Stateless

셋째로 요청들은 서로 의존성이 있으면 안되고 각각 독립적으로 처리되어야합니다.

 

4. Cacheable

서버가 보내는 자료들은 캐싱이 가능해야합니다.

그러니까 자주 받는 자료들은 브라우저에서 하드에 저장해놓고 

서버에 요청을 날리는게 아니라 하드에서 뽑아쓰는걸 캐싱이라고 합니다. 

 

5. Layered System 

서버기능을 만들 때 레이어를 걸쳐서 코드가 실행되도록 만들어도 된다고 합니다. 

 

6. Code on demand

서버는 실행가능한 코드를 보낼 수 있습니다. 

 

 

그래서 이런 원칙들을 잘 지키면서 서버 API 만들면 그걸 REST아니면 RESTful API 라고 부릅니다. 

그런데 잡배 아저씨 한명의 졸업논문일 뿐이라 근본은 별로 없는 개념이고

저걸 정확히 지키는 서버도 거의 없고 추상적인 포인트도 많아서 권장사항으로만 참고만 해두면 되겠습니다.

요즘은 그냥 method, URL만 잘 기입해두면 관습적으로 REST하다고 부릅니다. 

 

실은 와전된 다른 뜻도 있는데

서버에서 html을 보내는게 아니라 array, object 데이터만 달랑 보내는 API들을 REST API라고 가끔 부르기도 합니다.

 

 

 

 

더 나아가서 URL 이름지을 때도 몇가지 원칙들을 지키면 좀 이쁘고 이해가 쉬운 URL을 만들 수 있는데 

 

- 단어들을 동사보다는 명사 위주로 구성함

- 띄어쓰기는 언더바_대신 대시-기호-사용

- 파일 확장자 쓰지 말기 (.html 이런거)

- 하위 문서들을 뜻할 땐 / 기호를 사용함 (하위폴더같은 느낌)

 

예를 들어

facebook.com/bbc/photos

instagram.com/explore/tags/food

이 URL들은 매우 잘 만든 것 같지 않습니까. 

 

왜냐면 facebook.com/bbc/photos 이거 딱봐도 BBC뉴스 페북계정의 사진첩인 느낌이 들지 않습니까. 

instagram.com/explore/tags/food 이건 뭐같습니까. 

해시태그 #food 달린 사진들을 가져다줄거같지않습니까? 

한 눈에 딱 보이는군요. 

 

 

이런 식으로 이해가 쉽고 깔끔하게 만들면 좋습니다.

앞으로 서버 API에서 URL 작명할 때 한번 생각해봅시다.