그래서 Rest API가 뭐란 말입니까...

말은 많이 들었다. Rest API, Restful API... 취직공고에도 쓰여져 있고, 몇가지 문제를 해결하려고 검색하다 조금만 타고 들어가면 흔히 볼 수 있다.

그런데도 모르겠다! 몇 번 찾아보다가 아, 그런건가 싶어 넘어가면 다음에 또 잊어버리고, 프로젝트 하다가 여기에 rest api를 사용할 수 있나 싶으면 이미 사용하고 계시잖아요? 라는 말을 듣고(...) 

그래서 결국은 정리하기로 했다. 시작!

(주의사항 : 공부하는 입장이니 틀린 정보가 있을 수 있습니다....)

 

 

1. API?

그럼 가장 먼저 아주 자주 쓰이는 API라는 게 뭔지부터 알아보자. 

API = Application Programming Interface

 

위키백과에 따르면, 응용 프로그램에서 사용할 수 있도록 운영 체제나 프로그래밍 언어가 제공하는 기능을 제어할 수 있게 만든 인터페이스를 뜻한다고 한다. 

 

찾아보니 키보드라는 비유도 있고, 식당의 웨이터에 비유하기도 하던데. 개인적으로는 웨이터 비유가 더 마음에 든다.

 

손님(=개발자) 이 파스타가 먹고싶어서 식당에 간다. 자리에 앉으면 웨이터(=API)가 와서 메뉴판을 건네주고 묻는다.

'무엇을 주문하시겠습니까?' (=어떤 기능을 사용하시겠습니까?)

그럼 손님은 파스타를 주문하고, 웨이터는 주문을 받아 주방에 전달한다. 요리가 완성되면 웨이터는 주방에서 요리를 받아 손님에게 전달한다.

이 과정에서 손님은 주방에서 어떻게 요리를 하는지, 웨이터가 어디서 요리를 가져오는지 알 필요가 없다. 몰라도 손님은 주문을 하고, 돈을 지불하는 것만으로도 파스타를 먹을 수 있다.

 

카카오 지도 api를 사용한 적이 있는데, 그것도 위와 같을 것이다.

api가 내게 카카오가 만든 지도 기능 중 무엇을 사용할 것이냐고 묻고, 나는 형식에 알맞게 원하는 기능을 주문한다. 예를 들면 x, y 좌표를 주었을 때 해당 위치에 핀을 찍고 건물 이름을 띄우는 기능을 요청한다. 그럼 api가 알아서 뚝딱뚝딱 그 기능을 가져오는 것이다. 내가 알맞은 형식으로 주문만 했다면. 

 

즉, 굳이 복잡한 과정을 알 필요 없이 원하는 것을 요청시 원하는 기능을 얻게 해주도록 만들어진 서비스 정도로 이해하면 될 것 같다.

 

 

2. 그럼 Rest는?

 

REST = Representational State Transfer

멋대로 해석하자면 표현적인 상태 전송? 대표적인 상태 전송?

 

대략적으로 설명하자면, 요청을 봤을 때 그게 뭘 위한 요청인지 누가봐도 알 수 있도록 한 약속이랄까, 형식이라고 한다. 

 

만약 내가 회원가입 관련 기능을 짜고 있는데, 혼자 개발한다면 회원가입시 db에 새로운 회원을 넣는 요청을 /insert 라고 하든 /newmember 라고 하든 /nnnnnnn 이라고 하든 상관이 없다. 그런데 이제 다른사람과 같이하는데 그런 식으로 사용을 했다가는.... 음....

 

그래서 필요한게 rest라고 한다. 굳이 설명하지 않아도, 굳이 이게 무슨 요청인지 뜯어보지 않아도, 그냥 요청만 보고도 이게 어떤 어떤 데이터(혹은 자원)을 어떤 식으로 사용할건지 알 수 있게 하는 것.

 

그럼 이걸 어떻게 해야 다른 사람도 알아볼 수 있게 할 수 있을까?

 

요청을 하려고 하면 http라는 규약을 따라 신호를 전송해야 하는데, 이 http에는 많은 메소드가 있다고 한다.

이 때 rest하게 하려면, 즉, Rest를 사용하려면, 혹은 Restful 하게 요청을 작성하려면 그 많은 메소드 중 4~5가지를 사용한다. 

POST, PUT, GET, DELETE, (PATCH)

CRUD에 맞춰 설명하면

Create는 POST 메소드를,

Read는 GET 메소드를,

Update는 PUT이나 PATCH,

Delete는 그대로 DELETE 메소드를 사용한다. 

 

참고로 PUT의 경우엔 자원 전체(모든 필드)를 교체할 때, PATCH는 자원 중 일부(일부 필드)를 바꿀때 사용한다고 한다.

 

예를 들어보자.

 

영화예매사이트를 만들고 있는데, 모든 영화들을 전부 출력하고 싶다!

-> get 메소드 사용. /movies

 

새로운 영화를 등록하고 싶다!

-> post 메소드 사용. /movies

 

'아바타' 영화를 삭제하고 싶다!

->delete 메소드 사용. /movies/avatar

 

...이런식이다.

이 때 uri는 동사가 아니라 명사로 이루어져야 한다고 한다. 영화 등록하고 싶다고 /insertMovie를 사용하지는 않는다는 말.

 

결론?

REST는 다 알아볼 수 있게 만든 요청이다! 라고 생각하기로 했다.

 

그러니 Restful하다는 것도 어려운 말이 아니고 그냥 rest하게 만들었다 정도로 이해하면 될 것 같다.

 

 

 

3. 그래서 Rest API가 뭔데?

 

이제 rest가 뭔지 안다. API도 뭔지 안다.

다시 정리해보자면 rest -> 알아볼 수 있게 만든 요청, api -> 원하는 걸 요청시 원하는걸 얻을 수 있게 해주는 서비스.

정도로 이해하고 있으니 대강 합쳐보자면

원하는걸 요청시 원하는걸 얻을 수 있게 해주는 서비스(api)의 요청이 누구나 알아볼 수 있는 요청(rest)으로 되어 있는 것 즈음 된다.

 

간단히, REST 기반으로 구현된 API.

 

 

 

4. 그렇다면 규칙을 좀더 알아봅시다.

 

위에서 각각 crud에 따라 해당하는 http 메소드를 사용한다고 했다.

그럼 uri는 어떤식으로 짜야 Restful 한걸까?

 

1. 슬래시 ( / )는 계층 관계를 나타내는데 사용하기

2. URI 마지막에 슬래시를 포함하지 않기

3. 하이픈 ( - )은 URI 가독성을 높이는데 사용하기

4. 밑줄 ( _ ) 은 사용하지 않기

5. URI경로에는 대문자 사용 피하기

6. 파일 확장자는 URI에 포함하지 않기.

7. 리소스 간 연관관계가 있을 때는  /리소스명/리소스ID/관계가 있는 다른 리소스명

 

---

이정도면 대강의 이해는 된것 같다.

나중에 더 필요한 것이 있으면 추가 포스팅을 작성하거나 이 글을 수정하거나 해야겠다!

 

다음은 참고한 링크들

https://gmlwjd9405.github.io/2018/09/21/rest-and-restful.html

[Network] REST란? REST API란? RESTful이란? - Heee's Development Blog

https://velog.io/@somday/RESTful-API-%EC%9D%B4%EB%9E%80

RESTful API 이란