클라이언트? 서버? API? SDK? JSON? 이게 대체 무슨 말이야...?

@설명할 단어들.

1.클라이언트 - 서버 (Client - Server)

Request and Response

프론트엔드와 백엔드

 

2.IP, domain

 

3.API, CRUD

REST(restful api)

POST,GET,(PUT,PATCH),DELETE

 

4.HTTP 상태 코드

 

5.SDK

 

6.JSON

 

@1. 클라이언트와 서버,  Request와 Response, 프론트엔드와 백엔드

클라이언트(Client)는 번역하면 고객이고

 

서버(Server)는 번역하면 서빙을 제공하는 사람이다.

 

즉, 음식점에 갔다고 생각하면, 손님과 종업원인 셈이다.

 

손님(Client)과 종업원(Server)의 예시를 들어보자.

 

손님은 뭔가 부탁하는 사람이다. 우리는 핸드폰을 이용해서 많은 일들을 요청하곤 한다.

 

예를들어, 우리가 핸드폰을 이용해서 구글 플레이스토어에 들어가 어떤 앱을 다운로드한다고 하자.

 

이때, 우리는 네트워크망을 이용해서 구글 서버에 요청을 한다.

 

다시 말해 핸드폰이 구글 서버에 request를 보내고, 구글 서버는 해당 앱에 대한 파일을 핸드폰으로 보내며 response 한다.

 

여기서 핸드폰이 Client의 역할을 수행한다.

 

또한, 구글 서버가 Server의 역할을 수행하는 것이다.

 

구글 서버

다른 예시를 들어보자, LOL 게임을 하는 사람이라면, LOL Client라는 말을 많이 들어보았을 것이다.

 

우리는 LOL Client를 켜고, 로그인을 하며, 게임을 시작한다.

 

이때 Client는 해당 프로그램이다. 우리가 더블클릭을 통해 L 버튼을 눌렀을 때 켜지는 그 프로그램이 Client의 역할을 수행하는 것이다.

 

당연히 Server는 LOL의 회사가 갖고 있을 것이다.

 

Client는 이렇듯 어떤 요청을 하는 모든 것이다. 실체가 있는 핸드폰 또한 어떤 의미의 클라이언트고, LOL Client와 같이 어떤 프로그램이

 

클라이언트가 될 수도 있겠다.

 

이때, 이 클라이언트 쪽을 앞단, 즉 프런트엔드라고 명하며.

 

서버 쪽을 뒷단, 즉 백엔드라고 칭한다.

 

앞단과 뒷단을 사용자가 인식하는 현실

사용자, 즉 어떤 애플리케이션을 이용하는 사람은 실제로 해당 애플리케이션의 앞단 , 프론트엔드 쪽의 일들만을 보게 된다.

 

롤 클라이언트가 서버와 어떤 일을 주고받는지는 모르지만, 우리는 클라이언트를 켰을때 구입한 상품이 제대로 내 캐릭터에 입혀졌는지 

 

등을 확인하게 되겠지만, 뒷단에서 무슨 일이 일어나서 내 캐릭터에 상품이 입혀졌는지는 알 수 없다.

 

요약:

클라이언트 = 손님

서버 = 종업원

request = 주문

response = 종업원의 대답

프론트엔드 = 클라이언트

백엔드 = 서버

 

@2. IP, domain

손님이 종업원에게 주문을 한다고 생각하자.

 

이때 손님은 종업원이 어디 있는지 모른다면 당연히 주문할 수 없다.

 

이때 종업원의 위치를 IP라고 한다. 종업원은 서버이기 때문에 곧 서버 주소가 ip일 것이다.

 

구글 서버의 ip는 뭐 미국 워싱턴 ~~ 로 ~~ 길 이런 식일 수도 있겠지만 실제론 그렇지 않다.

 

네트워크 상의 규정에 따라, 192.168. xxx. xxx. 등의 숫자를 이용한 ip가 규정이다.

 

이 글을 보는 모든 이의 컴퓨터에도 ip가 존재한다. 우리가 어디선가 파일을 다운로드하기도 하지만, 동시에 업로드하는 일도 있기 때문이다.

 

즉 우리의 핸드폰은 클라이언트이면서 동시에 서버이다.

 

Win+r 을 누른 후, cmd를 치면

 

검은 창이 나온다.

 

이 창에서 ipconfig라고 작성한 후 엔터키를 누르면

 

각 사용자의 본인 컴퓨터 ip를 확인할 수 있다.

 

cmd창을 이용해 ip를 확인

 

우리가 예를 들어 서울 맛집에 대한 정보가 궁금해서 네이버 창에 검색을 했다고 가정하자.

 

이때 네이버는 서울 맛집의 정보를 제공하니, 하나의 서버이다.

 

그렇다면 우리는 이 서버의 위치를 어떻게 알았는가?

 

바로 www.naver.com 도메인을 알아서 접근했다.

 

숫자로 종업원의 위치를 매번 기억하는 것은 어렵고 불편하니 이렇듯 보기 쉽게 영어로 적은 것을 도메인이라 생각하자.

 

요약:

IP = 종업원의 주소

Domain = 종업원의 주소를 읽기 쉽게 바꾼 것

@3. API CRUD

API는 쉽게 말해서 다리(bridge)이다.

 

이전 포스팅에서도 설명한 바 있느냐 컴퓨터는 멍청하다.

 

따라서 다음과 같은 문장을 절대 이해할 수 없다.

 

"컴퓨터야 소, 독수리, 도마뱀을 포유류, 조류, 파충류로 나누어서 분류해줘 그리고, 포유류는 도축해줘."

 

라는 문장을 컴퓨터는 절대 이해할 수 없다.

 

하지만 어떤 경로(다리)를 만들어서

 

"컴퓨터야 A다리로 온건 포유류로 보내고 도축해"

"컴퓨터야 B다리로 온건 조류로 보내"

"컴퓨터야 C다리로 온건 파충류로 보내"

 

이건 할 수 있다.

 

이런 분류를  API라고 한다.

 

다시 말해, API는 한 소프트웨어가 다른 소프트웨어의 기능을 쓰기 위해 중간에 필요한 체계이다.

 

즉 손님이 직접 주방에 가서 주문을 해도 되지만 종업원의 주문하는 능력을 쓰기 위해

 

손님이 종업원에게 주문하는 체계인 것이다.

 

따라서 손님은 종업원에게 다음과 같이 주문한다.

 

종업원 IP / A다리

종업원IP / B다리

종업원IP / C다리

 

라고 주문한다.

 

추가:

{

하나의 함수라고 생각해도 좋을 것 같다. A다리로 보내면 포유류로 분류하고 도축하는.

}

 

CRUD는 데이터를 다룰 때 기준이 되는 요청이다.

 

각각 Create Read Update Delete인데

 

모든 데이터는 특별한 이유가 없는 한 4가지 기능에 동작하도록 관리되어야 한다는 것이다.

 

티스토리 블로그에 포스팅을 한다고 생각해보자.

 

그렇다면 나는

 

티스토리ip/post생성 이라고 (서버주소/Create)라는 api를 통해 데이터를 티스토리(서버)에 요청할것이다.

 

반대로 포스팅 한 게시글을 삭제하고 싶다면

 

티스토리ip/post삭제 라고 보낼 것이다.

 

만약 내 글을 보러 온 방문자는 내 게시글을 누르는 순간 티스토리ip/post읽기 라는 요청을 api를 통해 수행할 것이다.

 

update도 마찬가지다.

 

이런 CRUD에는 치명적인 문제가 있다. 바로 다뤄야 할 종류가 많아지면 해당 주소를 관리하기 복잡해진다는 것이다.

 

예를 들어 생성해야 할 것이 post 뿐만 아니라, 사진, 동영상, 메뉴 , 카테고리, 스킨 등등 많아지면 

 

티스토리ip/사진생성 , 티스토리ip/동영상생성 등 무수히 많은 주소가 발생하게 될 것이다.

 

따라서 이러한 문제를 해결하기 위해 REST 라는 체계적인 방법을 사용하자는 말이 나옵니다.

 

그런 API를 RESTful API 라고 합니다.

 

당연히 RESTful API 에선 사용되는 주소 개수가 이전보다 줄어듭니다.

 

Create : POST

Read : GET

Update : PUT(전체),PATCH(부분)

Delete: DELETE

 

로 다른 체계를 생성했으며

 

이때 (실제로 이렇게 되진 않지만) 다음과 같이 줄어들 수 있다.

 

티스토리IP/사진생성    -> 티스토리IP/POST/사진

티스토리IP/동영상생성 -> 티스토리IP/POST/동영상

 

@4. HTTP 상태 코드

다시 클라이언트와 서버로 돌아와서

 

클라이언트와 서버 간의 통신이 제대로 수행되었는지 알아보는 방법은 무엇이 있을까?

 

다시 손님과 종업원으로 돌아가자

 

상황1 : 손님이 종업원에게 케이크를 주문했고, 종업원은 손님에게 케이크를 대접했다.

상황2 : 손님이 종업원에게 브라우니를 주문했으나, 해당 메뉴는 메뉴판에 없어서, 종업원이 그런 메뉴는 없다고 했다.

상황3:  손님이 종업원에게 샌드위치를 주문했으나, 해당 메뉴를 식당에서 만들 여력이 없어서, 종업원이 그런 메뉴를 만들 수는 없다했다.

 

상황1은 아주 이상적인 상황이며

상황2는 손님이 잘못한 상황이고

상황3은 굳이 따지자면 종업원의 잘못이다.

 

이러한 상황이 당연히 클라이언트와 서버 사이에도 발생한다.

 

이런 상황이 발생했을 때 각각 200,400,500대의 상태 코드를 붙입니다.

 

200대는 모든 일이 GOOD 하다는 뜻이며

400대는 클라이언트가 요청에 문제가 있는 경우

500대는 서버에 문제가 있는 경우입니다.

 

다음과 같은 페이지를 본 적이 있을까?

 

404 NOT FOUND라는 상태 코드이다.

 

무슨 의미일까? 보통 어떤 웹페이지에 접속하려 했으나 실패했을 때 나오는 오류코드이다.

 

이제 400대의 의미를 알았으니 내가 요청한 페이지를 서버에서 갖고 있지 않다는 의미로써 해석할 수 있겠다.

 

@5. SDK

SDK는 API를 제공해주는 '다른 소프트웨어'이다.

 

앞의 예시를 들자면 누군가가 미리 A다리, B다리, C다리를 미리 생성해 둔 것이다.

 

그렇다면 나는 새로 API를 짤 필요 없이 누군가가 만든 것을 내가 갖다 쓰면 된다.

 

예를 들어, 내가 지도 서비스를 필요로 하는 모바일 앱을 만든다고 하자.

 

그렇다면 구글 지도 서비스를 이용해야 하는데,

 

이때 구글에서 지원하는 구글 지도SDK 를 이용해서 구글지도 서비스에 접근한다.

 

다시 말해, 내 앱("클라이언트") ->SDK(API) -> 구글"서버"의 지도

 

의 구조를 갖게 되는 것이다.

 

@6. JSON 

우리는 클라이언트가 서버로 보내는 request와 response에 대해서 알아보았다.

 

이때 request에도 데이터가 존재할 것이고 (위에 말한 소나 독수리가 각각의 data가 될 수 있겠다.)

 

response에도 데이터가 존재할 것이다 (도축된 소)

 

이런 데이터를 주고받는 것에 대한 규약 중 하나가 JSON이다.

 

규약이 없을 때를 생각해보자.

 

내가 LOL Client를 통해 로그인을 할 때 나는 아이디와 비밀번호를 작성할 것이다.

 

이때 작성한 데이터를 클라이언트는 무수한 방법으로 보낼 수 있다.

 

예를 들어,

id:홍길동

pw:1234

 

id  ----> 홍길동

pw ----> 1234

 

아이디는 ~ 홍길동

패스워드는 ~ 1234

 

등등 무수한 방법이 존재하나 이렇게 되면 개발자들 간의 의사소통 문제가 발생하므로 JSON이라는 규약을 통해 데이터를 주고받는다

 

물론 JSON이 아닌 XML과 같은 여러 다른 방법들도 존재한다.

 

JSON은 키(key)와 값(value)으로 구분되는데

 

다음과 같은 형식을 지닌다.

 

{

키1(key):값1(value),

키2(key):값2(value),

}

 

실제 값이 들어간다면 다음과 같다.

 

{

"id":"홍길동",

"pw":"1234",

}

 

요약:

클라이언트와 서버는 request와 response를 주고받으며 이때 포함되어 있는 data는 JSON 형식으로 주고받는다.

 

 

API 실습 링크 -> blossomwhale.tistory.com/8