API & REST API 개념

손님이 메뉴를 주문하려면 '메뉴판'을 보고 주문해야 한다. 

즉, 컴퓨터에게 요청을 할 때에는 정확한 주문방법에 따라 요청해야 한다. 

하지만, 우리는 서버가 어떻게 구성되어 있는지 알 방법이 없다.

우리가 서버코드를 직접 짠 사람도 아닌데 어떻게 사용 가능한 자원을 파악할 수 있을까? --> API(Application Programming Interface)

서버는 클라이언트에게 리소스를 잘 활용할 수 있도록 인터페이스(interface)를 제공해줘야한다. 이것을 API라고 한다. 

ex: API : 아메리카노 주문은 /americano로 요청하세요!

 

서버에는 마치 식당에서 메뉴판을 제공하듯이, 리소스를 활용할 수 있도록 API를 제공해야 한다. 

resoure: Americano

이 아메리카노를  주문할수있도록 하는것. ex: /americano

 

fetch API, method 이런것 전부 API

이런 API 종류가 적혀있는 곳 : API 문서 

 

서버가 리소스 전달을 위한 메뉴판, 즉 API를 잘 구축해놓아야 클라이언트가 이를 활용할 수 있다.

보통 인터넷에 있는 데이터를 요청할 때에는 HTTP라는 프로토콜을 사용하며, 주소(URL, URI)를 통해 접근할 수 있다.

 

 

1. 서버, 클라이언트란?

원래는 친구들이 우리집에 있는 컴퓨터에 영화가 많아서 같이 봤다.(탈것 : 자전거, 지하철, 자동차)

그런데 친구들이 놀러와서 안치우고 그래서 친구들이 놀러오지 않고도 영화를 보여줄 방법 생각.

내 컴퓨터를 인터넷에 올려두고 친구들에게 나의 집주소 대신 '컴퓨터 주소(IP주소)'를 알려준다.

이제는 교통수단을 타고 오던 친구들이 '크롬', '익스플로러'같은 브라우저를 타고 내 컴퓨터로 놀러올 수 있게 되었다.

 

내 컴퓨터 : 서버

내 컴퓨터 주소 : IP주소 또는 도메인

친구들 컴퓨터 : 클라이언트

 

 

2. 서버가 터진다는 의미는? 서버 컴퓨터가 렉이 걸리는 것. 

서버도 컴퓨터이다. 생각보다 너무 많은 친구들이 내 컴퓨터에 접속하면 렉이 걸릴 수 있다. 

한 컴퓨터로 친구들 100명이 동시에 영상을 보니 렉이 걸리다가 끝내 꺼져버리게 된다. 

이러한 상황이 생기면 안되니 회사들은 작은 컴퓨터가 아닌 본체를 몇백 개씩 쌓아둔 듯한 서버실을 가지고 있다. 

회사는 '서버'에 데이터를 저장하고 있고, 그것을 활용해 클라이언트에게 서비스를 제공.

 

3. 이미지가 클라이언트에게 있다는 것의 의미?

내가 웹사이트를 제작하였다. 광고도 넣고, 댓글 기능도 넣고. 이것저것 여러 기능들을 추가하였다.

기능이 추가되면서 보낼 데이터가 많아져서, 페이지를 클릭할때마다 모든 정보를 내 컴퓨터(서버)에서 보내다보니 서비스가 느리다는 불평이 나옴. 

 

그래서, 페이지가 바뀌어도 그대로인 데이터는 '서버'가 아닌 '친구들의 핸드폰'(클라이언트)에 저장하여 서버에서 보낼 데이터 양을 줄인다. 

서버에 저장할 것 : 페이지마다 변하는 광고사진, 영화, 프로필, 제목 등

클라이언트에 저장할 것 : 폰트, 아이콘 등

이렇게 클라이언트에 데이터를 저장하는 것 : 컴퓨터에선 '프로그램 설치', 스마트폰에서는 '앱 설치'

클라이언트에 다 넣으면 편할거라고 생각하지만, 클라이언트 데이터는 '수정이 어렵다'라는 큰 단점이 있다. 

잘못된 사진으로 클라이언트가 앱 설치를 했다면? --> "얘들아.. 미안한데 싹 지우고 다시 받아..." === 앱 업데이트

 

 

3. API가 문제라 JSON이 잘 안온다고..?

클라이언트와 서버의 대화방법 : API/JSON

앱을 만들었고, 앱에 다양한 기능도 추가되었다. 

덕분에 '회원가입 시켜줘', '영상 지워줘', '댓글 수정해줘' 등 클라이언트와 서버가 할 말이 많아졌다.

하지만 서버는 초인이 아닌 이상 24시간 동안 컴퓨터 앞에 앉아서 해당 요청들을 하나씩 대신 입력해줄수 없다. 

 

이걸 해결하기 위해 친구들의 컴퓨터(클라이언트)와 나의 컴퓨터(서버)가 대화하는 규칙을 만든다.

"앞으로 서버와 애플리케이션이 대화할때는 [서버야/ 이 동작을 / 여기에 해줘]처럼 하자" 라는 규칙

- 회원가입 시켜줘 : [서버야/만들어줘/아이디]

- 영상 지워줘 : [서버야/지워줘/영상]

- 댓글 수정해줘 : [서버야/수정해줘/댓글]

 

이렇게 약속이 정해진다면, 서버에서도 해당하는 위치에 오는 애들만 딱딱 분업해서 처리하면 된다. 

이러한 대화의 규칙을 API라고 부른다. 

그리고 이 메시지의 포맷을 JSON이라고 부른다. 

API의 규칙은 개발자 마음대로이다. 

 

[서버야/ 이 동작을 / 여기에 해줘] 처럼 하지 않고

[서버/1] : 회원가입

[서버/2] : 영상 업로드

이렇게 설정할 수도 있다. 

물론 혼자 쓴다면 상관없지만, 서버와 클라이언트 뿐만 아니라 내 서비스와 다른 서비스사이에서도 일어난다는게 문제.

나의 앱에 날씨 기능을 추가하고 싶으면 기상청 서버가 만든 API규칙에 맞춰 [기상청아/줘 / 내일 날씨] 같은 메시지를 보내야 한다.

하지만 기상청이 [서버/1] : 회원가입 와 같이 자신만 아는 API를 만들었다면? 개발자들이 아주 불편하다.

 

이렇듯 서로 다른 규칙때문에 전세계의 개발자들이 '야 이거 안되겠다. 통일하자'라는 생각을 하기 시작하였다. 

모든 요청들을

GET : 불러와줘

POST : 올려줘

PUT / PATCH : 수정해줘

DELETE : 지워줘

이렇게 4가지로 나눠준다. 

 

응답은

200 : 좋아

400 : 니가 잘못해서 싫어

500 : 내가 잘못해서 안돼

 

이렇게 함께 만든 통일된 대화규칙을 REST API