API를 사용은 해봤는데 무엇일까?
응용 프로그램에서 사용할 수 있도록 운영체제나 프로그래밍 언어가 제공하는 기능을 제어할 수 있게 만든 인터페이스이다. 조금 더 자세히 설명하면 프로그램과 프로그램 사이에 데이터를 주고 받기 위한 방법과 규칙이라고 할 수 있다. API는 데이터베이스가 아니지만 액세스 권한이 있는 앱의 권한 규정과 '서비스 요청'에 따라 데이터나 서비스 기능을 제공하는 메신저 역할을 한다.
API는 실제 눈에 보이는 UI가 아니라서 그저 말로 이렇게 들어도 어떤 것인지 잘 상상이 안되기때문에 열쇠, TV 리모콘, 점원 등 실제 눈에 보이는 중간 단계를 예를 들어 설명하곤 한다.
API의 작동 방식 4가지
API가 생성된 시기와 이유에 따라 다음과 같은 네 가지 방식이 존재한다.
SOAP API
SOAP(Simple Object Access Protocol)라는 명칭에서 볼 수 있듯이 그 자체로 프로토콜이며 보안이나 메시지 전송 등에 많은 표준들이 정해져있어서 유연성이 떨어지고 복잡하다. 이로인한 오버헤드가 많지만 분산환경에서 사용하기 적합하다. 클라이언트와 서버가 XML을 사용하여 메시지를 교환한다.
RPC API
RPC(Remote Procedure Call)은 원격프로시저 호출이라고 하며 매개 변수와 추가 정보를 직렬화하여 생성한 메시지를 서버로 보내면 서버에서는 받은 메시지를 역직렬화 하여 요청 받은 작업을 실행하고 그 결과를 다시 클라이언트에게 보내는 식으로 동작한다. 원격에 위치한 프로그램을 로컬에 있는 프로그램처럼 사용할 수 있지만 기반 시스템과의 결합도가 높고 제공하는 기능이 과다할 수 있다는 단점이 있다.
Websocket API
Websocket은 클라이언트 앱과 서버간의 양방향 통신이다. JSON 객체를 사용하여 데이터를 전달하는 또 다른 최신 웹 API 개발이며 서버가 연결된 클라이언트에 콜백 메시지를 전송할 수 있어 REST API보다 효율적이다. Stateful한 프로토콜이기 때문에 HTTP 사용시 요청마다 발생하는 TCP 3way handshake 과정을 피할 수 있어서 주로 실시간 업데이트가 매우 중요한 상황에서 활용 가능한 기술이다.
REST API
가장 많이 사용되고 유연한 API이다. 서버에 대한 클라이언트 요청이 URL과 유사하여 API 메시지가 의도하는 바를 쉽게 파악할 수 있다. HTTP 프로토콜의 인프라를 그대로 사용하여 별도의 인프라를 구축할 필요가 없다. 더 자세한 설명은 이전 포스팅(Rest API는 무엇이고 정말 대부분 잘못된 사용법을 가지는 것일까?)에 자세히 설명 되어있다.
API 유형
API는 작동방식 외에도 자바의 접근제한자처럼 사용(공개) 범위에 따라 크게 3가지로 나뉜다.
Private API
Private 단어의 뜻하는 바와 같이 공개되지 않은 내부 API를 뜻하며 회사 개발자가 자체 제품과 서비스를 개선하기 위해 내부적으로 발행한 API이다. 외부 제 3자에게 노출되지 않는다.
Public API
Public API
개방형 API로 누구나 사용할 수 있다. 이러한 API와 관련된 권한 부여와 횟수에 따른 비용은 각기 다를 수 있으며 제 3자가 API와 상호 작용하는 애플리케이션을 개발하여 혁신을 끌어낼 수 있다.
Partner API
기업이 데이터 공유에 동의하여 권한이 부여된 외부 개발자만 액세스할 수 있다. 비즈니스 관계에서 사용되며 파트너 회사 간에 소프트웨어를 통합하기 위해 사용된다.
API 생성 방법
AWS 페이지에서는 API 구축에는 실사와 노력이 필요하다고 한다. 특히 고품질 API 설계에 필요한 5단계에 대하여 아래와 같이 설명하고있다.
(1) API 계획
OpenAPI와 같은 API 사양은 API 설계를 위한 블루프린트를 제공한다. 다양한 사용 사례를 미리 생각하고 현재 API 개발 표준을 준수하는지 확인해야한다.
(2) API 빌드
API 디자이너는 상용 코드를 사용하여 API 프로토 타입을 생성한다. 프로토 타입이 테스트되면 개발자는 내부 사양에 맞게 이를 사용자 지정한다.
(3) API 테스트
API 테스트는 소프트웨어 테스트와 동일하고 버그 및 결함을 방지하기 위해 수행되어야 한다. API 테스트 도구로 사이버 공격에 대비하여 API를 강화할 수 있다.
(4) API 문서화
API는 그 자체로 설명이 필요 없지만 API 문서는 사용 편의성을 높이는 가이드 역할을 한다. 문서화가 잘 되어 다양한 기능과 사용 사례를 제공하는 API는 서비스 지향 아키텍처에서 더 많이 사용되는 경향이 있다.
(5) API 마케팅
API 마켓플레이스는 개발자가 다른 API를 사고 팔기 위해 존재한다. API를 나열하여 수익을 창출할 수 있다.
API를 사용하고 제공하는 이유가 무엇일까?
API가 어떻다는 것은 확실히 알겠는데 생성 시에 내 정보를 공유하기 위해서 규격도 만들어야하고 규격을 설명할 문서도 만들고 공을 들여야하는데 대체 이렇게 널리 사용되는 이유가 무엇일까?
그것은 기능 향상, 비용 절감, 기술 혁신, 운영 간소화 등의 다양한 이점이 있기 때문이다.
더 상세하게 말하면 우리가 가입할 때 네이버로 로그인, 구글로 로그인 등의 대형 플랫폼의 로그인 API를 이용하여 타 사이트를 이용하는 경우가 많다. 이렇게 번거로움을 줄여 그 사이트에 대한 사용자 이탈율을 저하시킨다.
그리고 많은 부분을 통합하고 표준화 하여 소프트웨어 통합 시 개발자들 간의 협업에서 조금 더 간소화되고 빠른 프로세스 처리를 하게하여 업무 능률을 상승시킨다.
또한 새로운 어플리케이션과 기존 어플리케이션 간에 유지, 관리, 보수가 쉬워진다.
하지만 언제나 그랬듯 단점 또한 존재하는데..
1. 보안성과 HTTP 방식의 제한
API의 단일 진입점인 API 게이트웨이는 해커의 타겟 대상이 될 수 있다. 평범한 HTTP 메소드를 사용해 액세스 할 수 있다는 API의 장점이 보안과 관련하여서는 오히려 단점이 되기 때문이다. 이때문에 메시지 가로채기 공격(man-in-the-middle), CSRF(Cross-Site Request Forgery) 공격, 크로스 사이트 스크립팅(Cross Site Scripting, XSS), SQL 삽입 공격(SQL injection), DDoS(Denial-of-service attack) 공격 (서비스 거부 공격) 등에 취약하다. 또한 HTTP Method는 메서드 형태가 다소 제한적이라는 문제도 가지고 있다.
2. 표준의 부재
REST API는 공식화된 표준이 없어서 개발자들 사이에서도 안티패턴을 판단하는 근거에 대한 논쟁이 자주 일고있다. 실제 표시된 근거가 없기 때문에 Google, Netflix, Amazone 등의 기업들이 표준역할을 하고있다. 그래서 REST API의 설계의 담당자도 자의적으로 판단 할 수 밖에 없어 안티패턴의 형태로 발전하는 경향이 있다.
3. 개발 비용
API 기능을 구현하고 제공하려면 개발 시간, 지속적인 유지 관리 요구 사항 및 지원 제공 측면에서 비용이 많이 들 수 있다. 또한 기존 API의 기능을 확장하려고 할 때 광범위한 프로그래밍 지식이 필요하다.
참조 Blog, Web
https://devkingdom.tistory.com/12 (SOAP API)
https://blog.wishket.com/soap-api-vs-rest-api-%EB%91%90-%EB%B0%A9%EC%8B%9D%EC%9D%98-%EA%B0%80%EC%9E%A5-%ED%81%B0-%EC%B0%A8%EC%9D%B4%EC%A0%90%EC%9D%80/ (SOAP API)
https://velog.io/@halonso14/%EC%84%B8-%EB%B2%88%EC%A7%B8-%EC%9E%91%EC%8B%AC%EC%9D%BC%EC%9D%BC-API-%EC%95%84%ED%82%A4%ED%85%8D%EC%B2%98-%EC%8A%A4%ED%83%80%EC%9D%BC-%EB%B9%84%EA%B5%90-2-RPC (RPC API)
https://junseokdev.tistory.com/m/57 (Websocket API)
https://docs.aws.amazon.com/ko_kr/apigateway/latest/developerguide/apigateway-websocket-api-overview.html (Websocket API)
