원티드 프리온보딩 과정에서 멘토님이 설명해주신 내용을 정리하고 이해하기 위해 이 글을 포스팅합니다.
명확이 이해하고 알고 있는 내용을 전달하기 위함이 아닌 스스로 개념을 정리하고 이해하고자 쓴 글임을 감안하고 읽어주세요.
조언과 피드백은 감사히 받겠습니다.
🧱 API
REST API를 이해하기에 앞서 API에 대해 알아보자.
나에게 api는 약속에 가까운 이미지다. 처음 api를 설계할 때 자주 들었던 말은 클라이언트(프론트 개발자)와 서버(백엔드개발자)간 협의를 통해 정해지는 규칙이라는 말이었다. 백엔드 개발자인 나의 입장에서는 api를 개발할 때 사용할 url, method, 논리적 & 물리적인 이름, permission(허가,권한), request 요청인자, response 정보 등을 사전에 협의하여 협의된 명세서 내용으로 api를 개발하는게 내가 경험한 api이다.
그렇다면 API의 정의는 무엇일까?
API는 Application Programming Interface(애플리케이션 프로그램 인터페이스)의 줄임말입니다. API의 맥락에서 애플리케이션이라는 단어는 고유한 기능을 가진 모든 소프트웨어를 나타냅니다. 인터페이스는 두 애플리케이션 간의 서비스 계약이라고 할 수 있습니다. 이 계약은 요청과 응답을 사용하여 두 애플리케이션이 서로 통신하는 방법을 정의합니다. API 문서에는 개발자가 이러한 요청과 응답을 구성하는 방법에 대한 정보가 들어 있습니다.
그저 정의만 복붙하고 넘어가면 당연히 이해가 되지 않기에 내 방법대로 해석을 해보자.
위에서 정의하고 있는 api는 '애플리케이션 프로그램 인터페이스'의 줄임말이다.
애플리케이션은 또 고유한 기능을 가진 모든 소프트웨어라고 할 수 있다. 여기까지 다시 정의를 해보면 api는 '고유한 기능을 가진 소프트웨어 프로그램 인터페이스'이다.
인터페이스는 두 애플리케이션 간의 서비스 계약이라고 할 수 있다. 그렇다면 api는 '고유한 기능을 가진 소프트웨어 프로그램의 서비스 계약'이라고 할 수 있겠다.
계약은 요청과 응답을 사용하여 두 애플리케이션이 서로 통신하는 방법을 정의한다고 한다.
최종적으로 api는 '고유한 기능을 가진 소프트웨어 프로그램 서비스의 요청과 응답을 사용여 통신하는 방법'이라고 할 수 있겠다.
결국 요약하면 서비스의 통신 방법 정도가 되지 않을까?
구글링을 통해 내가 내린 결론
여기까지 해석을 해보아도 2% 부족한 느낌에 구글링을 조금 해봤다.
결론적으로 API 의미를 받아들이기 위한 가장 쉬운 이미지는 '통로'라고 생각한다.
그렇다면 API의 자체적인 의미는 서비스를 이용하기 위한 통로이고 API를 제공한다는 의미는 서비스의 통로를 제공한다 정도가 되지 않을까?
결국 API를 개발하는것은 통로를 만드는 것이며 사용자가 이 통로를 통해 우리의 서비스를 이용할 수 있게 통로를 제공하는게 API를 제공한다고 할 수 있겠다.
앞선 해석과 구글링을 통해 내린 API의 나만의 정의
'서비스간 통신하기 위한 통로'
여기까지 해석을 하고 나니 내가 앞서 생각한 api는 원활한 통신을 하기 위한 규칙을 정하는 것이었고 본질적인 api와는 거리가 좀 있었다고 생각한다.
🧱 REST API
이제 API는 조금 감이 잡혔는데.. REST API는 뭘까?
REST API(RESTful API, 레스트풀 API)란 REST 아키텍처의 제약 조건을 준수하는 애플리케이션 프로그래밍 인터페이스를 뜻합니다. REST는 Representational State Transfer의 줄임말입니다.
위의 인용문에서 REST 아키텍처의 제약 조건을 준수하는 API라고 설명하고 있다. API의 의미는 전과 동일한데 추가적인 조건을 지키는 API인 것이다.
REST 아키텍처는 뭘까?
구글에서 정답을 찾기보단 또 한번 나만의 방법으로 접근해보자.
Representational State Transfer를 단어 그대로 해석하면 '대표 상태 이전'이다. 약간의 의역을 한다면 상태를 전달하는 대표적인 방법이라고 해석을 해볼 수 있겠다. 어떤것의 상태를 전달하는 걸까? 주변에서 주워 들었던 단어를 하나 꺼내보면 rest api를 얘기할 때 꼭 리소스(자원)를 얘기했던게 생각났다.
'리소스 상태를 전달하기 위한 대표적인 방법을 따르는 API' 여기까지가 내가 생각한 REST API이다.
왜 REST API가 필요했을까?
규칙 없이 저마다의 API를 개발을 하는데서 오는 어려움, 각각의 API를 개발할때마다 문서화의 비용이 컸기에 필요성이 커졌다고 생각한다. '누가 봐도 깔끔하고 알아보기 쉽고 이해하기 쉽게 규칙을 정해 놓으면 적은 비용으로 개발을 원활하게 할 수 있겠다'라고 생각하며 REST API를 만들지 않았을까?
REST API 구글링
REST API의 구체적인 개념은 'HTTP URL을 통해 자원(Resource)을 명시하고, HTTP Method(POST, GET, PUT, DELETE)를 통해 해당 자원에 대한 CRUD를 적용하는 것'을 의미한다고 한다. REST API를 쉽게 이해하기에 좋은 설명이다.
REST API는 장점만 있는게 아니다. 단점도 있으며 이 단점을 잘 보완하고 설계하는게 결국 RESTful한 개발의 핵심이 아닌가 싶다. REST API의 역사와 개념 등에 대해 전부 다루기에는 내 공부가 많이 부족하기에 개념적인 설명은 좋은 레퍼런스를 공유하며 마치도록 한다.
[무려 2009년에 정리된 자료이다. 최신 자료와는 다른 부분도 있을 수 있으나 13년전에는 rest api에 대해 어떻게 생각했고 어떤 고민이 있었는지 볼 수 있는 좋은 자료이다.]
[HANAMON에서 정리한 자료이다. 가독성이 좋고 이해하기 쉽게 설명이 되어있다.]
[AWS 자료이다. 동영상 자료도 있고 네임밸류(?)가 있는 자료여서 가져왔다.]
https://aws.amazon.com/ko/what-is/restful-api/
[IBM 자료이다. 역시 네임드 기업의 자료여서 가져왔으며 rest api의 우수사례가 기재되어 있는데 한번 훑어본 것만 가지고는 이해가 잘 가지 않는다.]
https://www.ibm.com/kr-ko/cloud/learn/rest-apis
오늘 포스팅은 여기까지,
다음에는 REST API의 사례에 대해 공부하고 직접 url과 mothod를 설계하고 왜 이런 설계가 필요한지 공부해보자.
'코딩 > 기타' 카테고리의 다른 글
uWSGI 플러그인을 찾지 못하는 오류 해결 (0) | 2022.08.09 |
---|---|
무한 스크롤 구현하기 (intersections observers로 스크롤 페이지네이션) (0) | 2022.04.10 |
<Github> switch 명령어 (0) | 2022.03.25 |