개발 전반에 걸쳐 API라는 단어를 정말 많이 사용하고 있다. 물론, 이 과정이 꼭 필요하다고 할 수는 없겠지만,
API의 워딩을 깊게 바라보는 것은 개발 역량 자체에 큰 도움이 될 것이라 생각해, 정리글을 하나 작성한다.
사실 모국어 한국어가 아닌 영어였다면, 단어 각각이 의미하고 있는 바를 이미 알고 있을 것이고, 결합어를 이해하는 데에도 별다른 어려움이 없을 것이라 생각하지만, 본토가 한국이니까 ^_^ 열심히 공부해보자!
cf.) 팁이라면 개념, 관계, 모든 방면에 있어서
- 이미지화를 시키자!
A to B Imaging - 그리고 육하원칙을 적용시켜 보자
육하원칙 적용하기
블로그 글을 링크하니 읽어보면 분명 도움이 될 듯 하다.
API : Application Programming Interface
뒤에서 앞으로 단어를 이해해보자.
1. Interface : 서로 다른 두 개의 시스템, 장치 사이에서 정보나 신호를 주고받는 경우의 접점이나 경계면이다.
위키백과에 이렇게 기술이 되어있는데, 아직 글의 이해가 잘 되지 않는다면, 일단 최대한 간단화를 시켜보는 것이다. 시스템, 장치, 정보, 신호 다 빼라. 상관없다.
Interface 는 서로 다른 두 개의 무언가(시스템, 컴퓨터, 노드, 사람, ...extra 모든 간에)에서 어떠한 무언가를 하는 (경우, 경우의 시점, 경우의 무언가...).
이 정도만 이미지만 가져갈 수 있다면 개인적으로 50%는 이미 도달했다고 보는 생각이다.
Interface에 좀 더 구체적인 설명은 Typescript type / interface 글에서 진행을 하겠다.
(바로 들어가서 볼 필요는 없지만, 꼭 봐야하는 주제는 맞다고 생각을 한다.)
Typescript type / interface
2. Programming : 프로그래밍. 추가 설명이 필요할까?
3. Application : 애플리케이션.
결국 application, programming 역시나 시스템, 컴퓨터 ... 등의 Characteristic 한 성격인 것이고, 굳이 스켈레톤 정도의 정의에서 넣지 않아도 되는 단어들인 것이다.(+ 정확히는 점진적으로 추가하는 방법으로 바라보아야 하는 것이다.)
이를 적용시켜보면
API : 두 개의 무엇간의 관계 -> 내가 어디서 뭘 가져올 때 -> 내가 Client의 입장으로 어떠한 Server에서 Data를 요청할 때 -> 기존의 흔히 알고 있는 API
요정도가 될 것이다.
이게 이해가 되었으면, 이제서야 RESTful API를 바라볼 준비가 되는 것이다.
RESTful API : Adj.) Representational State Transfer 한 API
: HTTP 기반의 웹에서 사용되는 RESTful API
API를 이해했다. 그런데 이제 앞에 접두어가 하나 붙었다. 그런데, 단어가 좀 처럼 다가오질 않는다. 그나마 Transfer만 조금 친숙한 기분이 든다. 아, 그럼 저것도 Character를 나타내는 것일 수 있겠구나, 하고 한 번 위키백과 등을 찾아보는 것이다.
간단한 의미로는, 웹 상의 자료를 HTTP위에서 SOAP이나 쿠키를 통한 세션 트랙킹 같은 별도의 전송 계층 없이 전송하기 위한 아주 간단한 인터페이스를 말한다.
하나의 개념을 보면, 또 추가적인 개념들이 쏟아져 나오기 때문에 이 행위가 굉장히 더디고 깊이를 요하는 것을 안다.
cf.) 나는 이 키워드들을 학습하는데 정보처리기사를 이용했다.
아무튼, ~~한 API라는 것을 인지한 채로, REST를 좀 더 파보자.
REST 아키텍처에 적용되는 6가지 제한 조건
- 다음 제한 조건을 준수하는 한 개별 컴포넌트는 자유롭게 구현할 수 있다.
- 인터페이스 일관성 : 일관적인 인터페이스로 분리되어야 한다
- 무상태(Stateless): 각 요청 간 클라이언트의 콘텍스트가 서버에 저장되어서는 안 된다
- 캐시 처리 가능(Cacheable): WWW에서와 같이 클라이언트는 응답을 캐싱할 수 있어야 한다.
잘 관리되는 캐싱은 클라이언트-서버 간 상호작용을 부분적으로 또는 완전하게 제거하여 scalability와 성능을 향상시킨다. - 계층화(Layered System): 클라이언트는 보통 대상 서버에 직접 연결되었는지, 또는 중간 서버를 통해 연결되었는지를 알 수 없다. 중간 서버는 로드 밸런싱 기능이나 공유 캐시 기능을 제공함으로써 시스템 규모 확장성을 향상시키는 데 유용하다.
- Code on demand (optional) - 자바 애플릿이나 자바스크립트의 제공을 통해 서버가 클라이언트가 실행시킬 수 있는 로직을 전송하여 기능을 확장시킬 수 있다.
- 클라이언트/서버 구조 : 아키텍처를 단순화시키고 작은 단위로 분리(decouple)함으로써 클라이언트-서버의 각 파트가 독립적으로 개선될 수 있도록 해준다..
처음 보면 좋은 키워드는 Stateless, Cacheable 정도가 아닐까 생각을 한다. 지식이 더 쌓이고, 필요성을 알게되면 그때 또 공부하면 되는 것이다.
결론으로,
API란 단어는 무조건 깊은 이해가 필요하다. 혹시나, 처음 개발을 하고 있는 사람 중 API에 헷갈리는 사람이 있다면 이 글을 참고할 수 있으면 정말 좋겠다.
