티스토리 뷰

2019년 2월, 첫 구직 당시였습니다. 면접관이 준 시험지 중에 이런 문항이 있었습니다. 

 

"REST API란 무엇인가?" 

 

사실 저는 이미 REST API를 이용한 웹 서비스를 만들고 있었습니다. REST의 일부인 GET과 POST 메소드를 이용해 데이터를 조회하고 또 생성하고 있었으니까요. 그럼에도 REST API가 어떤 것인지는 정확히 잘 몰랐죠(사실 우리가 정확히 알지 못하고 그냥 넘어가는 것들이 얼마나 많습니까?). 그래서 그 문항은 그냥 백지로 냈습니다. 면접관이 물어보더군요. 

 

면접관 : REST API에 대해 잘 모르시나요?

나 : 네.. 그냥 HTTP로 통신할 때 지켜야 하는 규약 정도로 알고 있었어요.

면접관 : 아.. 그래도 앞으로 웹에서 일할 일이 많다면 이 정도는 알고 계시는 것도 좋을 것 같아요~^^

나 : 네 알겠습니다^^

 

그리고 떨어졌습니다. ㅎ 

 

그 이후로도 공부하기를 계속해서 미루고 미루다가, 어쩌다 시간이 남는 날이 생겨 REST API에 대해 드디어 약간의 지식을 쌓을 수 있었습니다. 오늘은 그것에 대해 공유해보고자 합니다. 

 

REST API는 Representational State Transfer라는 용어의 약자입니다.

한글로 직역하면 '표현 상태 전송' 정도가 될 수 있겠네요.

 

사실 REST API를 이해하는 데 첫번째 장벽은 저 이름 자체인 것 같습니다. '표현 상태 전송' 이라는 말이 우리에게는 쉽게 와닿지 않기 때문이죠. 어째서 저런 이름을 가지게 되었는지부터 한번 살펴봅시다. 

 

REST API의 창시자인 로이 필딩(Roy Thomas Fielding) 박사는 웹 애플리케이션을 가상의 상태 관리 기계(virtual state-machine)로 보았다고 합니다. 이 기계의 상태는 사용자가 링크를 클릭함으로써 바뀌게 되는 거죠.  

 

이런 관점에서라면 '표현 상태 전송' 이라는 직역이 약간은 이해가 될 것 같기도 합니다. 하나의 가상 상태 관리 기계는(웹 앱) 내부에 나름의 표현 가능한 상태들을 가지고 있고(로드 가능한 웹 페이지들), 사용자가 상태 변경을 시도할 때마다(링크 클릭) 그 상태를 사용자에게 전송해서(transfer) 보여주는 것이죠(represent state).

 

REST API가 적용된 웹 애플리케이션은 무수히 많습니다만, 그 중 가장 중요한 것은 바로 WWW(월드 와이드 웹)입니다. 그렇습니다. WWW도 사실은 하나의 소프트웨어입니다. 그 소프트웨어는 인터넷 위에 올라가 있죠. 우리가 아는 수많은 웹 서비스는 인터넷 위의 웹 생태계 위에서 작동하는 것이고요. WWW는 HTTP의 안 좋은 네트워크적 특성에도 불구하고 REST API를 적절히 사용함으로써 수많은 콘텐츠를 담은 웹 생태계를 안정적으로 구축할 수 있었습니다.

 

이름에 대해서는 약간 알 것 같으니 실제로 사용할 때에 대해서 한 번 알아보겠습니다. 

사실 REST API도 파고들면 정말 공부할 게 엄청나게 많습니다만 이번에는 2가지 관점에서만 보겠습니다.

1. 자원

2. 메소드

위 2가지만 알아도 HTTP 통신을 할 때 REST API 비스무리하게 인터페이스를 구성할 수 있습니다.

 

먼저 자원에 대해 알아보겠습니다. 

REST 관점에서 자원이란 컴퓨터 시스템으로 표현할수 있는 모든 것을 말합니다. 웹 페이지가 될 수도 있고, 그 안에 담기는 데이터, 혹은 사용자가 될 수도 있죠.

 

자원은 써야 제맛입니다. 그런데 자원을 제대로 쓰려면 그 자원이 어떤 자원인지 식별해야만 합니다. 뭔지도 모르고 사용할 수는 없으니까요. 그 시각에서 나온 개념이 바로 URI(Uniform Resource Identifier) 입니다. 

 

URI 하면 떠오르는 게 하나 더 있죠. 바로 URL입니다. 

URI와 URL의 차이점은 무엇일까요? 사실 저도 몰라서 이번에 공부하게 됐습니다. 

 

URI / URL / URN

우선 결과적으로는 URI가 URL의 상위개념입니다. 각각의 약어가 어떤 단어의 약자인지를 알면 조금 더 명확해지는데, 앞의 UR은 모두 Uniform Resource로 똑같고 맨 뒷자만 보면 URI의 i는 identifier, 즉 그 자원의 전반적인 식별 규약을 말하고, URL의 L은 Locator의 약자로 식별 규약 중 그 자원의 위치를 중심으로 표현한 것이라 볼 수 있습니다. 잘 쓰이지는 않지만 URN이라는 개념도 있는데, URN은 위치에 상관없이 해당 자원의 이름을 식별하는 규약입니다. 

 

이제 URI가 뭔지도 알았으니, 그 식별 체계에 따라 인터페이스를 작성해야 합니다. 하지만 글이 너무 길어지는 것 같아, 일단 여기서 마무리하고 2편에서 다시 REST API를 따른 HTTP 인터페이스를 작성하는 방법에 대해 알아보도록 하겠습니다. 

 

감사합니다. 

 

참고

https://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm

 

 

 

'이론' 카테고리의 다른 글

REST API에 대해 - 2  (2) 2019.11.02
공지사항
최근에 올라온 글
최근에 달린 댓글
Total
Today
Yesterday
링크
«   2024/03   »
1 2
3 4 5 6 7 8 9
10 11 12 13 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29 30
31
글 보관함