쌀 팔다 개발자

말 그대로 정말 초보자를 위한 REST API 설명이다.

그 동안 개발을 하면서 RESTFUL하게 코드를 설계하였나? 라고 하면...
딱히 대답할 말이 없었다.

REST가 무엇인지 몰랐고, 또 이게 왜 필요한지도 잘 몰랐다.
사실 그 동안 REST API에 대해서 검색도 많이 해보고 많이 찾아보기도 했는데,
그 당시의 나의 수준에서 이해하기 어려웠는지, 이해가 잘 되거나 와닿지 않았다.

그러다가 정말 초보자 수준에서 이렇게 설명하면 좋을 것 같다는 생각이 들어
내가 느낀 대로 REST API를 정리해보려고 한다.

일단 REST API를 알려고 하면 API를 알아야 한다.

API는 Application Programming Interface의 줄인 말이다.
Application들이 서로 통신할 수 있도록 도와준다고 생각하면 될 것 같은데,
우리는 프론트와 서버가 통신하기 위해 API를 활용한다.

예를 들어 보자.

이런 상황은 얼마든지 발생할 수 있다. 또 반대로 금은방에 가서 돼지 불백을 주문하는 불상사가
생길 수 있다. 사실 이런 상황은 프론트와 서버와의 통신간에 더 많이 발생할 수 있다.

그러기 위해 서로 약속을 해야 한다. 이런 인터페이스를 사용하겠다는..
그게 API다. 다시 API의 보면 Application Programming Interface이다.

Programming Interface 개발을 위한 인터페이스인데, Application 간의 통신을 위한 인터페이스

자 여기서 한번 더 들어가보자. 이제 프론트와 서버간의 통신을 위한 인터페이스는 정했고,

그럼 REST API란 무엇일까?

아래의 상황을 보자.

음식점에 왔고, 손님은 이번에는 금값을 묻거나 그런 것이 아니라 정말 "음식"이라는 것을 잘 주문했다.
이 상황을 보고 나면 사실 인터페이스 뿐만 아니라 또 한번의 "약속"이 필요하다는 것을 느낄 것이다.

즉 어떻게 요청 할 것인지에 대한 약속. 그것을 위해 생겨난 것이 REST API다.(와 길게 왔다...)

REST API는 서버와 프론트 간에 어떻게 요청하고, 어떻게 전달 받을지에 대한 "약속" (효율을 높이기 위해!) 이라고 하면 좋겠다.

일단 REST API에 대한 정의를 보자.

참고 : mangkyu.tistory.com/46

일단 CRUD를 알아야 할텐데 Create, Read, Update, Delete의 줄인 말이다.
사실 우리가 통신할 때 하는 행동은 대부분 위의 4가지 이다. 이거는 조금만 고민해 보면 아는데, 게시판에 글을 적는다는 것은 Create하는 행위 일 것이고, 다른 게시판으로 이동하는 것은 Read하는 행위, 게시글을 수정하는 것은 Update, 게시글을 지우는 것은 Delete이다.

그럼 이 CRUD한 요청을 보내기 위한 "약속"이라고 볼 수 있는데 REST API에는 3가지의 구성 요소가 있다.

URI : product/32(id) => 서버는 요청에 대한 고유 id의 값을 가지고 있고, 해당 id로 요청을 보낸다는 것 1가지

METHOD : GET/POST/PUT/DELETE => 여기 드디어 나왔다. GET과 POST!

Representation of Resource : Json, XML, TEXT => Json은 여기에 숨어 있었다. JSON!

API의 효율적 통신을 위해 다시 한번 약속을 한 것이 REST API라고 했다. 이제 하나씩 보자.

URI에 대한 것은 조금만 눈치가 빠른 사람이라면 알 수 있다.
아래의 네이버 영화 페이지의 URL이다.
https://movie.naver.com/movie/bi/mi/basic.nhn?code=180378

여기서 제일 위의 code=180378 이라고 나오는데 여기 코드 번호를 하나만 바꾸면 또 새로운 영화로 바뀌면서 영화 정보가 나오는 것을 볼 수 있다.

그럼 다시 REST API 3가지 구성 요소 중 URI에 대한 부분을 보자.
"서버는 요청에 대한 고유 id의 값을 가지고 있고, 해당 id로 요청을 보낸다"

이제 이 말이 조금은 이해가 될 것이다. 해당 API(영화 정보를 조회하는 api는 https://movie.naver.com/movie/bi/mi/basic.nhn?

여기 제일 위에 code= 와 같이 조회할 영화 정보를 넣는다는 것이 REST API 약속 중 한 가지이다.

그럼 2번 째 드디어 나온.. 우리가 너무 자주쓰고 있는 GET과 POST가 나왔다.

"정보를 요청할 때는 GET 요청을 보내고,
정보를 입력할 때는 POST로 요청을 보낸다."
이렇게 약속을 해놓은 것이다. 이렇게 되면 서버에서는 프론트에서 GET 요청이 올 때는 DB에서 데이터를 조회해서
보내주는 로직으로 구성하면 되고, POST 요청이 오면 작성에 대한 로직을 구성하면 되기 때문에 굉장히 효율이 높아지게 된다.

이렇듯 REST API는 API 통신이 원활하기 위해 또 한번 약속을 해놓은 것이라고 볼 수 있다.

실제 REST에 대한 백과사전을 찾아보면

REST(REpresentational State Transfer) :

“Representational State Transfer라는 용어의 약자로서 2000년도에 로이 필딩 (Roy Fielding)의 박사학위 논문에서 최초로 소개됨. 로이 필딩은 HTTP의 주요 저자 중 한 사람으로 그 당시 웹(HTTP) 설계의 우수성에 비해 제대로 사용되어지지 못하는 모습에 안타까워하며 웹의 장점을 최대한 활용할 수 있는 아키텍처로써 REST를 발표”

와 같은 글을 볼 수 있다.

그럼 이제 마지막 Representation of Resource : Json, XML, TEXT 을 보자.

서버에서 프론트로 값을 줄 때 항상 JSON 형태로 전달을 하고 있어서 그냥 그런가 보다 생각을 했었는데,
이것도 REST API의 일부였다..!! 

서버에서 프론트로 결과 값을 줄 때 JSON/XML/TEXT 등의 값으로 반환한다는 것을 정의 해놓은 것인데,
이렇게 되면 프론트엔드 쪽에서도 어떤 형태로 값이 넘어올지 미리 예상할 수 있어 이렇게 맞추어 코딩을 하면 된다.

현재는 JSON 위주로 쓰이고 있어서 우리는 보통 서버에서 프론트로 반환 값을 줄 때 JSON형태로 전달하고 있다.
JSON은 key와 value로 이루어진 값의 모임인데 간단하게 형태를 예시로 들어보면 아래와 같다.

와 이제 정말 다 설명했다.

정리를 다시 해보자면

API 사용하기 위해서는 약속이 다시 한번 필요했고! 이 약속을 효율적으로 한 것이 REST API라는 것.
RESTFUL하게 구성하였냐는 이 REST의 구성요소 들을 잘 지키면서 API를 작성했는지에 대한 것이다.

나처럼 헤메고 있는 누군가에게는 도움이 좀 되었으면 좋겠다.


ps . 저와 같이 초보자를 위해 정리한 것이라 다소 틀린 부분이 있을 수 있습니다.

Webhook과 API. 

참 개발을 하면서 많이 듣는 단어이다.

api는 (Application Promgramming interface)의 줄인 말로 API는 응용 프로그램에서 사용할 수 있도록, 운영 체제나 프로그래밍 언어가 제공하는 기능을 제어할 수 있게 만든 인터페이스를 뜻한다.라고 위키에 나와있다.

오히려 이런 정의를 접하고 나니깐 더 어려워진다. 응용 프로그램은 우리가 만들고 있는 서비스 혹은 제품이라고 생각하면 될 것 같고, 운영 체제나 프로그래밍 언어는 우리에게 정보를 제공해주는 곳이라고 생각하면 될 것 같다.

우리는 정보를 제공해주는 곳에 API를 보내면 해당 정보들로 반환을 해서 준다. 흐헝 이것도 어려우니깐 이해가 잘 되도록 적어놓으신 글을 첨부 [API 란? - 초보개발자 - Medium](https://medium.com/@dydrlaks/api-%EB%9E%80-c0fd6222d34c)

아무튼 특정 서비스에서 정보를 얻어오는 방법은 크게 2가지로 나뉘어진다.

Webhook 혹은 API, 2가지 모두 그 서비스에서 제공을 해줘야지만 가지고 와서 쓸 수 있다.

webhook과 api의 가장 큰 차이는 api는 우리가 요청했을 때 해당 서비스에서 요청한 자료를 주는 것이고 webhook의 경우에는 해당 서비스에서 우리가 설정해놓은(또는 제공해주는) 특정 변화가 있을 때 해당 정보들을 보내준다.

웹훅의 이점에 대해 atlassian에서 잘 정리해놓아서 가지고 와본다.

Advantages of webhooks

Without webhooks, if you want to detect when events occur in Bitbucket Cloud, you need to poll the API. However, polling the API is inconvenient, inefficient, and error-prone. Consider how SMS messages work on mobile phones. You don't have to check your messages every 5 minutes to see if you have a text because your phone sends you a notification. In the same way, webhooks work like the notification so that the API does not have to check for the same activity every minute.

• 즉 우리의 휴대폰에서 5분마다 메시지가 왔는지 확인하는 것은 매우 비효율적이다. 따라서 우리는 메시지가 올 때만 알람을 듣고 확인하게 하는데, 5분마다 폰을 켜서 메시지가 왔는지 확인하는 것은 api, 그리고 그 메시지가 왔을 때 알람을 주는 것은 webhook이다.

=> 해당 글은 현재까지의 이해도를 바탕으로 작성하고 있어, 틀린 부분이 많을 수 있습니다. 댓글 적어주시면 앞으로 고쳐가도록 하겠습니다!