[4장-1] API와 SDK

 

 

---

▶ API

 

API가 뭘까!!🤔

 

자. 카카오톡을 생각해 봅시다.

 

클라이언트 컴퓨터와 서버 컴퓨터가 있죠? 

클리이언트는 서버에게 요청을 보냅니다.

 

"메시지, 비디오 파일, 이미지 파일을 줘."

"로그인, 회원가입 시켜줘."

"이 메시지 삭제해줘."

 

그럼 서버는 요청에 따라 적합한 처리를 해서 응답을 줄 거에요.

근데, 컴퓨터는 한글을 몰라요...😢

그래서 어떤 요청이 '메시지를 달라'는 요청인지, '로그인 시켜줘'라는 요청인지 알 수 없죠..

 

 

이 요청을 컴퓨터가 구분할 수 있도록 하는 '체계'가 필요했어요.

 

그 체계가 바로 API에요!!

 

API = 클라이언트, 서버와 같은 서로 다른 프로그램에서 요청과 응답을 주고 받을 수 있게 만든 체계

 

이렇게 생각하면 돼요.🧐

 

 

 

 

 

그럼 이제 API는 어떻게 진행되는지 알아볼까요?🧐

 

요청을 보내는 쪽과 응답을 주는 쪽.

이렇게 나뉘어져 있어요.

(스마트폰(클라이언트 컴퓨터)은 요청을 보내고, 서버 컴퓨터는 요청을 받아서 응답을 주는 거죠.)

 

 

이렇게 진행되려면, 응답을 주는 쪽에서 미리!

'여기로 요청하면 이런 응답을 주고, 저기로 요청하면 저런 응답을 줄게'

이런 걸 정해놔야 해요. 

 

그래야 요청하는 쪽에서 '정확한 곳'에 요청을 보낼 수 있겠죠??

 

 

이 '정확한 곳'은 '서버주소/A'의 형태의 주소로 정의되어 있어요.

(여기서 '서버주소'는 [03장]에서 정리했던 IP 주소에요!)

 

 

이 주소 뒤에 어떤 문자를 쓰느냐에 따라 다른 기능을 수행하도록 정의하는 거죠.

 

 

A는 '로그인 기능', B는 '회원 가입 기능', ...

이렇게 알맞게 서버가 응답할 수 있게 되는 거에요.

여기서 응답은 '잘 되었다', '문제가 있다', '문제가 있다면 무슨 문제인지', 등등.... 알려줍니다.

 

(이 기능은 서버 개발자가 만들어요. 그 결과물이 바로 서버 프로그램이에요.

서버 주소 정의 역시 서버 개발자에 의해서 이루어져요.)

 

 

 

정리하자면

API는 서버 개발자가 개발하고, 클라이언트 개발자는 그 API를 사용한다.

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

쉽게 말해, 기능을 사용하기 위해 주소로 요청을 보내면 응답을 해주는 소프트웨어끼리의 체계이다.

 

 

 

 

➕ 한 가지 더 추가

 

API를 만들 때는 데이터를 주고 받는 기능도 함께 넣어요.

(로그인 요청시, 아이디와 비밀번호 데이터 필요

비디오 파일이나 이미지 파일에 대한 응대을 받을 때, 데이터 필요)

 

API를 통해 요청과 응답을 주고 받을 때는 데이터도 같이 담긴다. 알아둡시다!🤓

 

 

 

 

 

 

 

 

▶ 클라이언트와 서버의 관점

 

▷ 클라이언트

클라이언트의 관점에서 봅시다. 서버에 요청을 보낼 때, 이 요청에는 4가지 요소로 나눌 수 있어요.

 

<CRUD>

C: Create → '올리는' 요청

R: Read → '불러오는' 요청

U: Update → '바꾸는' 요청

D: Delete → '지우는' 요청

 

 

CRUD는 아주 중요하기 때문에 개발자들은 데이터를 볼 때 항상 CRUD의 관점에서 생각해요.

(만약, CRUD 중 특정 기능이 없는 기획이라면, 그 기획 의도가 명확해야 하고, 이유도 설명할 수 있어야 해요.)

 

 

 

CRUD의 예시를 한 번 볼까요?

 

타임라인의  CRUD 요청은 각각의 주소를 가집니다.

C의 경우, '서버 컴퓨터 주소/timelinecreate'

R,U,D도 각각의 주소를 가져요.

 

이렇게 각각 주소가 있어야 클라이언트가 원하는 기능에 알맞는 해당 주소로 요청을 보낼 수 있겠죠?

 

 

 

근데, 여기서 문제가 뭘까요?

이렇게 주소를 구성하다 보면, 주소가 너무 많아지고 관리하기 힘들어진다는 거예요.

지금은 4개라 와닿지 않겠지만, 이런 주소가 10000개라고 생각해 보세요. 머리 터지겠죠...?😅

그리고 이렇게 많아지면, 주소들은 기능이 겹칠 수 있어요.

 

이러한 이유로 조금 더 체계적인 API,

API를 REST(Representational State Tranfer)한 API,

RESTful API가 만들어지게 됩니다.

 

RESTful API에서는 전보다 주소의 개수가 줄어들어,

CRUD를 하나의 주소로 관리해요.

그리고 요청을 보낼 때, 아래와 같이 어떤 요청인지 파악할 수 있게 스티커를 함께 붙여 전송해요.

 

C: Create(생성해줘) → POST

R: Read(불러와 줘) → GET

U: Update(바꿔줘) → PUT(전체) / PATCH(일부)

D: Delete(지워줘) → DELETE

 

 

💡이 5개의 스티커는 자주 쓰이니 꼭 알아둡시다!!(↑↑↑)

 

💡RESTful API는 모든 회사에서 통용되는 규칙이 아닌 일종의 사회 운동이에요.

상황마다 다양한 방식으로 변형해서 사용해요. 이 점도 알고 넘어갑시다.

 

💡참고로, 현업에서는 '스티커'라는 용어를 사용하지 않아요.대신, '메소드(Method)'라는 용어를 사용해요.

➕ 함수에서는 x를 '변수', '파라미터(Parameter)'라고 표현해요.

 

 

 

 

 

 

 

 

▷ 서버

이번에는 서버의 관점에서 봅시다.

 

클라이언트에게 받은 요청을 서버는 다음과 같이 생각해요.

 

'요청을 보낸 사용자가 가입된 사용자인가?'

'비밀번호가 틀렸다! 확인해 보라고 말해줘야겠다.'

'친구 중에 A를 찾아달라고? A는 없는데? 없다고 말해줘야겠다.'

'친구 목록을 보내 달라고? 친구가 없는데?'

'비밀번호를 잊어버렸다고? 재설정이 필요한지 물어봐야겠다.'

 

위와 같이 컴퓨터가 생각할 수 있다는 것은 서버 개발자가 코딩했다는 것을 의미해요.

 

 

코딩에 따른 응답에는 2가지 경우가 있어요.

하나는 '잘 됐어'

다른 하나는 '잘 안 됐어' 에요.

 

 

그리고 표현 방법은 정말 다양해요.

'잘 됐어' → 'Good', 'Great', 'Ok', 'Success'  or 'a', 'b' or '잘 됐어'

라고 표현할 수도 있죠.

 

 

 

 

여기서 발생하는 문제는 뭘까요?

 

50개의 부서가 있다고 가정해봅시다. 

각 부서에서 '잘 됐어'라는 응답을 서로 다르게 준다면...?

받는 사람 입장에서는 그 모든 표현을 하나하나 대응하는 코드를 만들어야 하니...

굉장히 곤란하겠죠?

 

그래서 개발자들은 '잘 됐어', '잘 안 됐어'에도 체계가 필요하다고 생각했어요.

 

'잘 됐어'는 200번대 코드로,

 

'잘 안 됐어'는 두 가지 경우가 있어요.

① 클라이언트 요청에 문제가 있어서 안 된 경우 (400번대 코드)

② 서버 내부적으로 잘 안 된 경우 (500번대 코드)

 

이렇게 다르게 표현하면, 문제가 발생했을 때 원인을 찾기 더 쉬워지겠죠?

 

모든 코드를 암기할 필요는 없어요.

200, 400, 500의 큰 틀에서 이해하면 됩니다.

그 중에서도 자주 쓰이는 코드가 있는데, 계속 듣다 보면 익숙해질 거예요.

 

 

 

 

 

 

 

 

▶SDK

 

API를 제공해주는 '다른 소프트웨어'를 'SDK'라고 불러요.

SKD는 Software Delvelopment Kit의 약자로, 소프트웨어를 개발하기 위한 도구에요!

 

'○○소프트웨어'를 개발할 때 도움을 주는 '다른 소프트웨어'라고 생각하면 됩니다.

 

보통 다른 회사와 협업할 때, SDK라는 이야기를 듣게 될 거에요.

 

 

 

예시를 한 번 살펴볼까요?

 

구글 지도는 구글에서 만든 소프트웨어에요. 

이때 다른 회사들도 구글에서 제공하는 지도 SDK를 설치하면,

자신들의 소프트웨어에 구글 지도 기능을 넣을 수 있게 되는 거예요.

 

이 SDK에서 제공해주는 API들을 통해 구글 지도에 요청을 보낼 수 있어요.

 

 

 

---

 

 

 

 

지금까지!

클라이언트가 서버로 보내는 '요청(Request)'과

서버가 클라이언트로 보내는 '응답(Response)'에 대한 내용이었어요.

그리고, 그 요청과 응답에 데이터를 넣을 수 있는 '기능'을 같이 개발해야 한다는 내용도 있었죠.🤓

 

다음 장에서는 그 '기능'의 여러 가지 형식에서 공부하려고 해요.🧐

궁금하다면, 다음 장 '[04-2장] JSON'으로 GO!

 

 

 

 

 

 

 

 

 

 

_Next

JSON

 

 

 

 

 

 

 

 

 

(참고)비전공자를 위한 이해할 수 있는 IT지식_T.W.I.G