애플리케이션 프로그래밍 인터페이스 ( Application Programming Interface )의 약자
애플리케이션 소프트웨어를 구축하고 통합하기 위한 정의 및 하위 함수, 프로토콜, 도구들의 집합
명확하게 정의되어 있는 다양한 컴포넌트 간 통신 방법
당사자들 간 계약을 나타내는 Documentation을 갖춘 계약으로 비유되기도 함
2) API 이점
구현 방식을 모르는 제품 또는 서비스가 서로 커뮤니케이션 가능
애플리케이션 개발 간소화로 시간과 비용 절약
새로운 툴과 제품 설계 또는 기존 툴/제품 관리 실행 시 유연성 제공
설계/ 관리/ 사용 방법을 간소화 하며 혁신 기회 제공
3) API 작동 방식
한쪽 당사자가 특정한 방식으로 구성된 원격 요청을 보내면 다른 쪽 당사자의 소프트웨어가 응답하는 방식
클라우드 네이티브 애플리케이션 개발을 통해 자체 인프라를 연결하는 간소화된 방식
그러나 고객 및 다른 외부 사용자와의 데이터 공유를 허용하기도 함
개발자가 새로운 애플리케이션 구성 요소를 기존 아키텍처에 통합하는 방식을 간소화
API 관계도
4) API 정책
프라이빗 ( Private )
API를 내부에서만 사용할 수 있도록 하며, 기업이 API를 최대한으로 제어할 수 있다.
파트너 ( Partner )
API를 특정 비즈니스 파트너와 공유하며, 품질 저하 없이 추가 수익원을 창출할 수 있다.
퍼블릭 ( Public )
API가 모두에게 제공되며, 제 3자가 API와 상호 작용하는 애플리케이션을 개발하여 혁신을 끌어낼 수 있다.
"Public API 가 될 때 가장 중요한 것은 ‘인터페이스 안정성’이다. 파라미터 하나를 추가하는 것 조차도 기존 고객들의 시스템을 파괴해 버릴 수 있다. 그래서 Public API 로 배포되는 경우 아직 개발 중이라면 unstable(불안정) 할 수 있다고 반드시 표시를 해 주어야 한다. "
RESTful
1) RESTful 이란?
웹 API가 확산되면서 정보 교환 표준화를 위해 개발된 사양으로는 프로토콜인 SOAP ( Simple Object Access Protocol ) 와 Architecture 스타일인 REST (Representational State Transfer ) 이 두가지가 있다.
SOAP
XML 메시지 형식 사용
HTTP / SMTP 를 통한 요청 수신
보다 간편한 방법으로 앱을 다양한 환경에서의 실행, 다양한 언어를 이용한 작성이 가능
2) REST 등장 배경
2000년도에 로이 필딩 (Roy Fielding)의 박사학위 논문에서 최초로 소개
HTTP의 주요 저자 중 한 사람으로써 웹(HTTP) 설계의 우수성에 비해 제대로 사용되어지지 못하는 모습을 안타까워 함
웹의 장점을 최대한 활용할 수 있는 아키텍처로써 REST를 발표
3) RESTful API
RESTful API : REST Architecture의 제약 조건을 준수하는 웹 API
공식적인 표준이 존재하지 않음
규정된 프로토콜보다 간단한 SOAP보다 높은 사용률을 보임
RESTful API 구성 요소
자원(Resource) : URI
행위(Verb) : HTTP Method
표현(Representations)
* OpenAPI 사양
REST API를 정의하는 공통 표준으로 급부상
언어 독립적 방식 > REST API 인터페이스 구축 > 사용자가 별 추측 없이 사용가능
4) RESTful API 제약조건
Client - Server Achitecture
REST 아키텍처 클라이언트, 서버, 리소스(Resource)로 구성되며 HTTP를 통해 요청을 처리
REST 서버 : API제공 / Client : 사용자 인증, 컨텍스트(Session, Login정보)등을 직접 관리
역할이 구분되어 개발 내용의 명확화 및 상호 간 의존성 감소
무상태성 ( Stateless )
REST 서버에는 들어오는 요청만 처리하도록 되어 있으며, 별도로 세션 및 쿠키 정보를 저장/ 관리 하지 않음
작업을 위한 상태 정보가 저장되지 않으며 이는 클라이언트 측에 저장됨
서비스 자유도 향상 및 서버 내 불필요한 정보의 부재로 단순화된 구현
캐시 가능성 ( Cacheable )
기존 웹 표준 HTTP 그대로 사용함 > 웹에서 사용한 기존 인프라 그대로 활용 가능
HTTP 프로토콜 표준에서 사용하는 Last-modified 태그 또는 E-Tag를 이용한 캐싱 구현 가능
계층화된 시스템
REST 서버는 다중 계층으로 구성되어 클라이언트-서버 간 상호 작용 조정 가능
보안, 로드 밸런싱, 공유 캐시와 같은 추가 기능 제공으로 구조 상의 유연성 실현 가능
Proxy, Gateway 와 같은 네트워크 기반 중간 매체 사용 가능
코드 온디맨드(옵션) :
서버가 실행 가능한 코드를 전송하여 클라이언트의 기능 확대 가능
통합된 인터페이스 : RESTful API 설계의 핵심으로 다음과 같은 4가지 측면을 포함
요청에서 리소스 식별: 리소스는 요청에서 식별되며 클라이언트로 반환된 표현으로부터 분리
표현을 통한 리소스 조작: 클라이언트가 리소스를 나타내는 파일을 수신
이 표현에는 조작 또는 삭제를 허용할 수 있도록 충분한 양의 정보가 포함되어야 함
자기 기술적(Self-descriptiveness) 메시지
클라이언트로 반환되는 메시지 : 클라이언트가 수행해야 할 정보 처리 방식을 충분히 기술해야 함
애플리케이션 상태 엔진으로서의 하이퍼미디어:
리소스 할당 후 REST 클라이언트가 하이퍼링크를 통해 현재 사용 가능한 기타 모든 작업을 탐색 가능
API , Restful
API
1) API 란?
2) API 이점
3) API 작동 방식
4) API 정책
"Public API 가 될 때 가장 중요한 것은 ‘인터페이스 안정성’이다.
파라미터 하나를 추가하는 것 조차도 기존 고객들의 시스템을 파괴해 버릴 수 있다.
그래서 Public API 로 배포되는 경우 아직 개발 중이라면 unstable(불안정) 할 수 있다고 반드시 표시를 해 주어야 한다. "
RESTful
1) RESTful 이란?
웹 API가 확산되면서 정보 교환 표준화를 위해 개발된 사양으로는 프로토콜인 SOAP ( Simple Object Access Protocol ) 와 Architecture 스타일인 REST (Representational State Transfer ) 이 두가지가 있다.
SOAP
2) REST 등장 배경
3) RESTful API
RESTful API 구성 요소
* OpenAPI 사양
4) RESTful API 제약조건
Client - Server Achitecture
REST 아키텍처 클라이언트, 서버, 리소스(Resource)로 구성되며 HTTP를 통해 요청을 처리
무상태성 ( Stateless )
캐시 가능성 ( Cacheable )
계층화된 시스템
코드 온디맨드(옵션) :
서버가 실행 가능한 코드를 전송하여 클라이언트의 기능 확대 가능
통합된 인터페이스 : RESTful API 설계의 핵심으로 다음과 같은 4가지 측면을 포함
요청에서 리소스 식별: 리소스는 요청에서 식별되며 클라이언트로 반환된 표현으로부터 분리
표현을 통한 리소스 조작: 클라이언트가 리소스를 나타내는 파일을 수신
이 표현에는 조작 또는 삭제를 허용할 수 있도록 충분한 양의 정보가 포함되어야 함
자기 기술적(Self-descriptiveness) 메시지
클라이언트로 반환되는 메시지 : 클라이언트가 수행해야 할 정보 처리 방식을 충분히 기술해야 함
애플리케이션 상태 엔진으로서의 하이퍼미디어:
리소스 할당 후 REST 클라이언트가 하이퍼링크를 통해 현재 사용 가능한 기타 모든 작업을 탐색 가능
참고:
https://www.redhat.com/ko/topics/api/what-are-application-programming-interfaces#
'Knowledge' 카테고리의 다른 글