[GraphQL]GraphQL이 등장하기 전 - Rest API란?

우선 API라는 것은 Application Programming Interface의 약자이다.

 

우리가 Interface라고 하는 것은 쉽게 비유해보자면 

Tv를 키고 끌때 리모콘을 사용하고 자판기에서 주문을 할 때도 자판기 버튼을 누르고 컴퓨터에서 키보드와 마우스를 통해서 정보들을 입력하고 선택하듯이 컴퓨터와 인간이 소통하는 창구를 Interface라고 한다.

정보를 입력하고 선택하는 것뿐만이 아니고 그러한 정보들을 볼 수 있는 모니터도 이 Interface에 속한다.

 

그럼 여기서 앞에 Application Programming이 붙은 Interface가 API 인 것이다.

 

무슨말이냐 하면

 

우리가 컴퓨터나 스마트폰을 보면 여러 버튼, 스크롤, 팝업창 등이 있다. 이것들을 통해 사용자가 그 프로그램을 제어하는데 이런 것들을 User Interface 즉, UI라고 한다. 이것은 기계와 인간 사이의 Interface인 것이다. 

 

하지만 기계와 기계 즉, 소프트웨어끼리도 소통할 수 있는 창구가 있어야 한다. 

기상정보를 관리하는 기상청 서버가 있는데, 다양한 웹사이트, 앱들에서 이 서버에 날씨데이터를 요청해서 우리에게 제공해주고 있다.

미리만들어진 소프트웨어를 통해 기상청 서버에 날씨정보를 요청하는데 이 요청하는것에도 일정한 형식이 있다.

예를 들면 날짜, 지역, 조회할 내용 등을 넣어서 요청하면 거기에 맞는 날씨정보를 보내주게 된다는 일정한 형식이 있다면 누구나 이 형식에 맞춰서 데이터를 보내는 프로그램을 만들면 누구나 이를 활용한 서비스를 만들 수 있을 것이다.

 

이처럼 소프트웨어가 소프트웨어에게 지정된 형식의 요청,명령등을 받을 수 있는 수단을 API라고 하는 것이다.

 

 

 

 

 

자 이제는 Rest를 알아보자.

Rest API 에서 Rest는 Representational State Tranfer의 약자로 자원을 이름(자원의 표현)으로 구분하여 해당 자원의 상태(정보)를 주고 받는 모든 것을 의미한다.

무슨 말이냐 하면

 

우리가 우체국에가서 택배를 보낼 때 송장증을 작성할 것이다.

 

이러한 송장증을 보면 누가, 무엇을 누구에게 어떤 주소로 보내는지 등을 송장증 형식에 맞춰 작성한다.

 

우체국직원뿐이 아닌 사람이 보더라도 언제 어디서 누가 무엇을 누구에게 어디로 보내는지 등을 알 수 있다.

이처럼 약속된 형식이 있는 것이다.

 

이런 것처럼 정해진 형식대로(Rest) 소프트웨어간의 소통방식(API)를 Rest API라고 한다고 할 수 있다.

이 Rest API에서 중요한 것이 각 요청이나 어떤 동작이나 정보를 위한 것인지를 요청모습 자체로 추론가능하다는 것이다.

 

 

※ 이해를 돕기위해 정말 간단하

 

 

 

 

사실 만들고자 하는 서비스에서 동작하는 것만을 생각한다면 이 Rest API를 생각하지 않고 그냥 막 만들면 될 것이다.

 

예를들면, 어떤 학원과 학생들에 관한 API를 만들고자 할 때 동작만을 생각해서 만든다면

//반 리스트를 가져오는 api
https:(도메인 주소)/1

//반 학생들의 리스트를 가져오는 api
https:(도메인 주소)/hello

//학생들의 정보수정 요청하는 api
https:(도메인 주소)/ilikecoffee

위와 같이 만들어도 된다.

 

참고로 위와같이 구분자를 이용해서 만드는 것을 URI라고 한다.

 

하지만 개발이라는 것은 혼자만 하는 것이 아니고, 차후 후임자를 위한 인수인계를 할 때도 인수인계가 없다면 후임자는 대체 저게 무슨 역할을 하는 것인지 알 수 없다는 것이다.

 

때문에 위 처럼 하지말고 요청주소 모습 자체를 봤을 때 누구나 추론할 수 있도록 api를 만들자라는 약속 또한 Rest API 라고 할 수 있다.

 

 

그러면 Rest API는 어떻게 씀?

Rest API는 간단하게

URI(Uniform Resource Identifier = 어떤 정보를) + 요청 방식(어떻게 할 것인가) 의 공식으로 소통한다.

 

URI는 보내거나 받을 데이터를 의미하고 

요청방식에는 다음과 같은 종류가 있다.

 

요청 형식	용도
GET	정보 받아오기
POST	정보 입력하기
PUT/PATCH	정보 수정하기
DELETE	정보 삭제하기

 

서버에 위 요청형식 중 하나를 선택하여 보내거나 받을 데이터를 같이 보내주면 해당하는 정보를 받거나 입력하거나 수정 및 삭제를 할 수 있다.

 

위와 같은 요청형식들을 사용하여 하는 작업들을 보통

Create(생성하기)

Read(조회하기)

Update(수정하기)

Delete(삭제하기)

줄여서 CRUD 작업이라고 한다.

 

서버에 Rest API를 이용해 통신을 할때는 HTTP(HyperText Transfer Protocol)이라는 통신규약을 통해 통신하는데 우체국에서 우편물을 붙일때 편지, 택배, 화물 등을 선택해서 보내는 것처럼 HTTP 라는 약속에 맞게 GET,POST,PUT,PATCH,DELETE라는 방식을 선택해서 보내게 된다.

 

 

 

자 위에서 봤던 막 만들었던 api 주소(?) 즉 URI를 Rest API 처럼 즉, 누가봐도 내용을 추론할 수 있도록 바꿔본다면

 

//반 리스트를 가져오는 api
GET + https:(도메인 주소)/classes

//1반 학생들의 리스트를 가져오는 api
GET + https:(도메인 주소)/classes/1/students

//1학생 중 번호가 3번인 학생의 이름을 PARK으로 수정 요청하는 api
PUT + https:(도메인 주소)/classes/1/students/3?name="PARK"

등으로 나타낼 수 있을 것이다. 누가봐도 내용을 추론할 수 있지않은가?

 

아님말고

 

아무튼 이렇듯 Rest에는 몇가지가 있는데 이건 google에 잘 나와있으니 참고해주시고 이런 규칙 즉, Rest규칙에 맞춰서 api를 만드는 것을 Restful 하게 api를 만드는 것 줄여서 Restful api라고도 한다.

 

 

 

 

 

 

오케이 Rest API 대충 이해했어. 그런데 왜 잘쓰다가 GraphQL이 등장했냐고?

 

초창기 Rest API 는 혼란스러운 서버시장에 혁신이었지. 하지만 이 Rest API에도 한계가 있기 때문이죠.

 

< Case 1. Overfetching >

 

만약 내가 어떤 팀을 관리하는 서버에 데이터를 요청하려고 하는데 나는 각 팀의 매니저와 사무실 호수만 필요하다고 가정해보자. 

 

그래서 나는 localhost:3000/api/team/ 로 데이터를 요청했더니 다음과 같은 데이터를 받은 것이다.

 

내가 필요한 데이터보다 많은 데이터를 받은 것이다.  이처럼 내가 필요한 데이터보다 많은 데이터를 받는 것을 overfetching이라고 한다.

 

만약 요청하는 데이터가 1억개라고 생각한다면 낭비되는 데이터가 많고 속도에 있어서도 느려질 것이다.

 

 

 

 

< Case 2. Underfetching >

이번에는 특정 팀의 매니저와 팀원들의 명단만이 필요하다고 가정해보자

 

근데 현재 만들어진 uri로는 특정 팀에 대한 정보를 요청하고 그 뒤에 받아온 팀에서 매니저와 팀원들의 명단을 또 요청해야한다.

 

이처럼 내가 원하는 데이터가 여러 계층(layer)에 걸쳐있어서 한번의 요청으로 충분한 데이터를 얻지 못하는 것을 underfetching 이라고 한다.

 

 

 

 

만약 한번의 요청으로, 내가 원하는 데이터만,  충분히 가져올 수 있다면 불필요한 데이터 낭비를 막고 통신속도에도 개선을 할 수 있지 않을까? 라는 고민들이 생기기 시작한 것이다. 

 

이러한 고민들로 인해 GraphQL이 등장하게 된 것이다.

 

다음 포스팅부터는 실질적으로 GraphQL을 알아보도록 하자.

 

 

 

 

 

 

 

출처 : 얇팍한 코딩 사전 : GraphQL & Apollo 강좌