WEB | API 알아보기

00. API ?

---

1) API 

: 애플리케이션 소프트웨어를 빌드하고 통합하기 위한 정의 및 프로토콜 세트인 애플리케이션 프로그래밍 인터페이스(Application Programming Interface)

 - 프로그램들이 서로 상호작용하는 것을 도와주는 매개체

---

01. API의 역할

---

1. 서버와 데이터베이스에 대한 출입구 역할

: 데이터베이스에는 소중한 정보들이 저장되므로, 모든 사람들이 이 데이터베이스에 접근할 수 있으면 안된다. 

⇒ API는 이를 방지하기 위해 서버와 데이터베이스에 대한 출입구 역할을 하며, 허용된 사람들에게만 접근성을 부여한다.

 

2. 애플리케이션과 기기가 원활하게 통신할 수 있도록 도움
: API는 애플리케이션(프로그램 등)과 기기가 데이터를 원활히 주고받을 수 있도록 돕는 역할을 한다.

 

3. API는 모든 접속을 표준화한다.
: API는 모든 접속을 표준화하기 때문에 기계/ 운영체제 등과 상관없이 누구나 동일한 액세스를 얻을 수 있다.

---

02. API 종류 : 프라이빗, 퍼블릭, 파트너

---

프라이빗
API를 내부에서만 사용할 수 있도록 하며, 기업이 API를 최대한으로 제어할 수 있다.

파트너
API를 특정 비즈니스 파트너와 공유하며, 품질 저하 없이 추가 수익원을 창출할 수 있다.

퍼블릭
API가 모두에게 제공되며, 제 3자가 API와 상호 작용하는 애플리케이션을 개발하여 혁신을 끌어낼 수 있다.

---

03. API 장단점

---

파트너와 퍼블릭 API의 경우 다음과 같은 장점이 있다.

 

• 새로운 수익 채널을 확보하거나 기존 수익 채널을 확장합니다.
• 브랜드 인지도를 확대합니다.
• 외부 개발을 활용하고 협업을 수행하여 오픈 혁신을 촉진하거나 효율성을 높입니다.

 

특정 파트너 또는 전 세계 사람들과 API를 공유하면 긍정적인 효과를 가져올 수 있으며 각각의 파트너십을 통해 브랜드 인지도 측면에서 회사 자체의 마케팅 활동을 넘어서는 성과를 거둘 수 있다. 퍼블릭 API처럼 기술을 모든 사람에게 공개하면 개발자가 API를 사용하여 애플리케이션의 에코시스템을 구축할 수도 있다. 

---

04. Web API

---

웹 API는 일반적으로 요청 메시지에 HTTP를 사용하여 응답 메시지 구조의 정의를 제공한다. 이러한 응답 메시지는 일반적으로 XML 또는 JSON 파일의 형태이다. 다른 애플리케이션이 쉽게 조작할 수 있는 방식으로 데이터를 표시하므로 XML과 JSON 둘 다 자주 사용된다.

---

05. SOAP 프로토콜과 Web API, REST 비교

---

웹 API가 확산됨에 따라, 정보 교환을 표준화하기 위해 SOAP(Simple Object Access Protocol)라는 프로토콜 사양이 개발되었다. SOAP로 설계된 API는 XML 메시지 형식을 사용하며 HTTP 또는 SMTP를 통해 요청을 수신한다. SOAP를 사용하면 더 간편한 방법으로 애플리케이션을 다양한 환경에서 실행하거나 다양한 언어로 작성하여 정보를 공유할 수 있다.

 ⇒ (* 추후 SOAP에 대해서도 알아보아야 할 것 같음)

 

또 다른 사양은 REST(Representational State Transfer)로, REST 아키텍처의 제약 조건을 준수하는 웹 API를 RESTful API(REST API)라고 한다. SOAP는 프로토콜이지만 REST는 아키텍처 스타일이라는 근본적인 차이가 있으며 따라서 RESTful 웹 API에는 공식적인 표준이 없다. RESTful 시스템의 다음 6가지 주요 제약 조건을 준수했을 때 RESTful API라고 간주할 수 있다.

• 클라이언트 서버 아키텍처: REST 아키텍처가 클라이언트, 서버, 리소스로 구성되며 HTTP를 통해 요청을 처리합니다.
• 스테이트리스: 요청이 통과하는 서버에는 클라이언트 콘텐츠가 저장되지 않으며 그 대신 세션 상태에 대한 정보가 클라이언트에 저장됩니다.
• 캐시 가능성: 캐싱으로 일부 클라이언트-서버 간의 상호 작용이 제거됩니다.
• 계층화된 시스템: 추가 계층으로 클라이언트-서버 간의 상호 작용을 조정할 수 있으며 이러한 계층은 로드 밸런싱, 공유 캐시 또는 보안과 같은 추가 기능을 제공할 수 있습니다.
• 코드 온디맨드(옵션): 서버가 실행 가능한 코드를 전송하여 클라이언트의 기능을 확대할 수 있습니다.
• 통합된 인터페이스: 이 제약 조건은 RESTful API 설계의 핵심이며 다음과 같은 4가지 측면을 포함합니다.
  1. 요청에서 리소스 식별: 리소스가 요청에서 식별되며 클라이언트로 반환된 표현으로부터 분리됩니다.
  2. 표현을 통한 리소스 조작: 클라이언트가 리소스를 나타내는 파일을 수신합니다. 이 표현에는 조작 또는 삭제를 허용할 수 있도록 충분한 양의 정보가 포함되어야 합니다.
  3. 자기 기술적(Self-descriptive) 메시지: 클라이언트에 반환되는 각 메시지에 클라이언트가 정보를 어떻게 처리해야 할지 설명하는 정보가 충분히 포함되어야 합니다.
  4. 애플리케이션 상태 엔진으로서의 하이퍼미디어: 리소스를 할당한 후 REST 클라이언트가 하이퍼링크를 통해 현재 사용 가능한 기타 모든 작업을 찾을 수 있어야 합니다.

 

제약 조건이 많아 보이지만 규정된 프로토콜보다는 훨씬 간단하기 때문에 RESTful API가 SOAP보다 더 많이 사용되고 있다.

---

참고자료

---

 

1. https://www.redhat.com/ko/topics/api/what-are-application-programming-interfaces

API란? What is API? API 뜻, API 개발 방식, API 연동, Web API

2. https://blog.wishket.com/api%EB%9E%80-%EC%89%BD%EA%B2%8C-%EC%84%A4%EB%AA%85-%EA%B7%B8%EB%A6%B0%ED%81%B4%EB%9D%BC%EC%9D%B4%EC%96%B8%ED%8A%B8/

API란? 비개발자가 알기 쉽게 설명해드립니다! - wishket