오늘 친구와 옛날 이야기를 하다가 입사 한 달차때 일화가 생각났는데 둘 다 너무 웃겨서 한참을 ㅋㅋㅋㅋ만 한참 두드렸어요🤣
부서배치 받고 첫 개발과제를 받았는데 사수분이 "API 호출부분부터 보시면 될 거예요." 라고 하셨어요.
지금생각해보면 아-주 친절하게 알려주셨는데 고등학교 때 배운걸 바로 까먹은건지,, "API...뭔 지는 아는데..뭔 지 모르겠다.."
바로 친구에게 SOS쳤는데 저와 별다를 것 없는 학교 생활을 함께한 친구가 해준 대답은
"/(슬래시) 이렇게생긴거..그게 API일걸?.."
그 날 이클립스에서 ctrl+h로 /만 한참을 검색한 저인데 어떻게 밥벌이를 하고있네요ㅋㅋ
아무튼! 생각난김에 API에 대해 정리해보자 합니다😉
📍 API(Application Programming Interface)란 ?
어플리케이션의 상호작용을 돕는 매개체 라고 한마디로 정의할 수 있습니다.
여기서 '인터페이스'는 두 프로그램간의 '계약' 개념과 유사합니다.
요청(Request)과 응답(Response)을 사용해서 통신하는 방법을 정의해둔 것!
이것을 API라고 보면 됩니다.
예를 들어서 치킨을 배달시키려고 한다고 가정해봅니다.
1) 배달 어플을 켜서 치킨을 주문한다.
2) 가까운 치킨집에가서 포장해온다.
결국 치킨을 주문하는건 똑같지만 주문 과정에서 각각 아래와 같은 매개체를 통한다는 차이가 있습니다.
1) 배달어플
2) 점원
이렇게 나와 치킨을 연결해주는 인터페이스 역할을 API가 해준다고 보시면 됩니다 .
치킨을 주문하려면 맛, 결제방법 등을 선택해야하겠죠?
원활한 통신을 위해서는 요청과 응답에 필요한 방법,값 등을 정의해야합니다.
마치 계약 처럼요 🍗
API는 프로그램/클라이언트(나)로 부터 계약된 방식에 따른 요청을 받아
어플리케이션/서버(배달어플/점원)과 상호작용하여 응답(치킨)을 제공합니다.
📍 API의 역할 ?
(1) Server - DB 의 '출입구'
API는 DB에 저장된 정보에 대한 접근성을 관리합니다. 또 서버에서 DB에 접근할 때 key인증 등을 통해서 보안을 설정할 수도 있습니다. 아무 서버에서나 데이터에 접근하면 안되니까요!
(2) App - Device 의 '통신망'
우리가 카톡창에 메세지를 입력하고 전송버튼을 누를 때, 복잡한 코드를 직접입력해야 한다면 아마 우린 다시 아날로그시대로 돌아가서 편지를 쓰게 될거예요 :) API는 어플리케이션에서 사용자의 동작을 서버가 알아들을 수 있는 형식으로 요청해주는 통신망의 역할을 합니다.
(3) 접속 표준화
스마트폰, 컴퓨터, 패드, 워치 등등 우리는 아주 다양한 형태로 어플리케이션을 사용하고 있습니다. API는 다른 기기와 운영체제에서도 동일하게 동작할 수 있도록 모든 접속을 표준화하는 역할을 해줍니다.
📍 API의 정책별 종류 ?
사용하는 곳에 따라서 정책별로 종류를 나눌 수 있어요.
크게 아래와 같이 세가지로 분류됩니다.
(1) Private : 기업 내부에서 사용하는 API
(2) Partner : 기업 내부 + 비즈니스 파트너(협력사)와 공유하는 API
(3) Public : 모두에게 공유되어 있는 Open API
Partner, Public API 정책은 수익을 창출하고, 브랜드 인지도를 향상시키기도 합니다.
📍 SOAP API ?
Simple Object Access Protocol의 약어로, 다른 언어로 다른 플랫폼에서 빌드된 애플리케이션이 통신할 수 있도록 설계된 최초의 표준 프로토콜입니다. XML 형식을 사용하고, 그 자체의 프로토콜이기 때문에 오버헤드의 발생확률이 있습니다.
(1) 아키텍처
-
UDDI : Universal Description Descovery Intergration
- 서비스의 CRUD를 관리하는 전역적 저장소(공개 레지스트리)
- 모든 데이터가 XML형태로 표현되고, 데이터&오퍼레이션이 WSDL로 정의되면 UDDI에 등록되어 누구라도 서비스를 찾을 수 있도록 공개됨
- 등록(Publish) - 탐색(Find) - 바인딩(Bind) -
WDSL : Web Service Description Language
- 웹 서비스의 구체적인 내용(서비스의 제공장소, 메시지 포맷, 프로토콜 등)을 기술함
(2) 동작
- Service requestor가 SOAP 으로 인코딩하여 웹 서비스를 Service provider 에게 요청
- Service provider는 이걸 디코딩해서 요청 받은 로직을 수행
- 결과를 SOAP로 인코딩해서 return
(3) 특징
- 복잡한 구조로 인해 오버헤드가 있다.
- 상대적으로 무겁고 속도가 느리며 개발 난이도가 높다.
- 보안 수준이 엄격하다.
- Session 등을 사용하여 Stateful 하다.
- POST 방식만 사용하여 모든 CRUD 작업을 수행한다.
- Proxy, F/W에 구애받지 않는다.
- 잘 정립된 웹 서비스 표준을 가지고 있다.
📍 REST API ?
Representational State Transfer의 약어로, ROA 설계의 Resource를 HTTP Method로 처리하도록 설계된 인터페이스입니다. ROA(Resource Oriented Architecture)는 Resource가 설계의 중심에 있는 S/W 아키텍처를 의미합니다. REST의 경우 SOAP과 달리 프로토콜이 아닌 가이드라인에 가깝기 때문에 이러한 권장 사항의 구현 여부는 개발자에게 달려 있습니다.
(1) 아키텍처
-
Resource(자원) : URI
- Server에 존재하며 모든 자원에 할당된 고유한 ID
- Client는 URI를 통해 Server에 요청함 -
Verb(행위) : HTTP Method
- HTTP Method와 동일함
- GET / POST / PUT / DELETE -
Representation(표현)
- JSON(가장 많이 씀), XML, TEXT, RSS 등 여러 형태로 Response를 보냄
(2) 특징
- Uniformed Interface : 일관된 인터페이스
- Resource에 대한 요청을 통일되고 한정적으로 수행하는 아키텍처 스타일이다.
- 플랫폼, 기술, 언어에 구애받지 않는 Loosely Coupling(느슨한 결합)을 가지고 있다.
- State Less : 무상태성
- 각각의 요청은 모두 독립적이다.
- Session, Cookie 의 정보를 활용하며 상태정보에 대한 저장이나 관리를 하지 않는다.
- 자유도가 높으며 서버에 부담이 덜하다.
- Cacheable
- 웹 표현을 그대로 사용하여 캐싱 기능을 적용할 수 있고, 때문에 대량 요청을 효율적으로 처리할 수 있다.
- Client - Server 구조
- Server는 API를 제공하고 Client는 사용자, 세션 관리를 하는 등 역할이 구분되어 있어 상호의존도가 낮다.
- Self Descriptiveness : 자체 표현
- URI + Parameter 조합으로 요청 내용을 파악할수 있다.
- Layer System : 계층화
- Client는 REST API Server 만 호출함
- REST API Server는 다중계층으로 구성할 수 있음 (Ex. Proxy, LB, GW등 N/w기반의 중간매체 사용 가능)
(3) REST API의 응답 종류
- 1xx : 전송 protocol 수준
- 2xx : Client의 요청 수행 성공
- 3xx : Client의 추가적 행동 필요
- 4xx : Client의 잘못된 요청
- 5xx : Server의 오류
(4) RESTful ?
REST를 REST 답게 쓰기 위한 가이드라인 이라고 볼 수 있지만, 여러 개발자들의 비공식적 의견 제시로 만들어졌다. 목적은 이해하기 쉽고 사용하기 쉬운 것에 있으며, 포인트는 자원(resource)에 대해 꼭 '복수형태'를 취한다는 것이다.
- 표준 RESTful API 형태
- 목록 GET : /resources
- 단일 GET : /resources/{id}
- 생성 POST : /resources + param
- 수정 PUT : /resources/{id} + param
- 삭제 DELETE : /resources/{id}
📍 정리하며
둘 중 뭐가 더 우수하다는 것은 없고 SOAP API는 금융권 서비스 처럼 보안수준이 높아야 하는 경우에, REST API는 확장성이 크거나 분산시스템에 용이합니다. 사실 프로토콜/API의 차이도 존재하기 때문에 제대로 된 비교가 힘들기도 합니다. 결론적으로는 서비스의 특성에 따라 선택하는 것이 현명한 방법 🤓
