API
Application Programming Interface
독립된 소프트웨어 응용프로그램(app)이 서로 통신할 수 있도록 하는 일련의 프로토콜, 루틴, 도구
서로 다른 소프트웨어 구성요소가 서로 상호작용할 수 있는 방법 제공
(한 app에서 다른 app이 제공하는 데이터 또는 기능, 서비스에 접근할 수 있도록하는 매개체)
-> 다양한 기술과 시스템을 보다 쉽게 통합 가능
고려 사항: 수행하는 작업, 제공 or 사용할 데이터의 종류, 사용 방법, End Point(클라이언트가 API와 상호작용하는데 사용할 URL), API가 사용할 형식(JSON, XML 등), HTTP 메소드(POST, GET, PUT, DELETE), 클라이언트가 보낼 입력 매개변수, 반환할 출력 데이터, 문서화 등
API 구현 방법
1. REST(Representational State Transfer)
HTTP를 통한 리소스 지향 통신
- HTTP 메서드(GET, POST, PUT, DELETE 등)을 사용하여 리소스에 액세스하고 작업을 수행하는 API 설계에 널리 사용되는 아키텍처 스타일
- 상태 비저장(stateless), 요청-응답 모델(request-response)
- 널리 사용되고 문서화가 잘되어있어 다른 시스템과 쉽게 통합하여 구현 가능
2. SOAP(Simple Object Access Protocol)
- XML을 사용해 시스템 간에 데이터를 전송하는 프로토콜
- SOAP API는 표준화된 데이터 교환 방법을 제공
3. GraphQL
- 클라이언트가 고정된 데이터 집합을 반환하는 대신 필요한 정확한 데이터를 지정할 수 있도록 하는 API용 쿼리 언어
- GraphQL API는 특히 복잡한 구조의 데이터에 액세스하는 보다 효율적이고 유연한 방법 제공
4. RPC(Remote Procedure Call)
서버에서 원격 기능을 호출하는 방법
- 클라이언트가 원격 서버에서 메서드를 호출하고 결과를 받을 수 있도록 하는 프로토콜
- RPC API를 사용하여 간단하고 효율적인 방식으로 원격 서비스 또는 기능에 대한 액세스 제공 가능
- 클라이언트, 서버가 미리 잘 알려져 있고, 미리 정의된 상호작용 기능 집합이 있는, 밀접하게 연결된 시스템에서 사용 가능
- XML, JSON, 바이너리를 비롯한 여러 인코딩 형식 지원
5. WebSocket
실시간 양방향 통신
- 클라이언트와 서버 간의 양방향 통신 채널을 제공하여 클라이언트에 실시간 업데이트 및 알림 보낼 수 있음
- 빈번한 polling, 응답-요청 주기 X -> 즉각적이고 지속적인 데이터 교환 허용하는 영구연결 제공 + StateFul
- 실시간 app 구축, 푸시 알람, 대화형, 실시간 업데이트 등에서 사용
RPC 란?
- 클라이언트 app이 마치 로컬 함수인 것 처럼 원격 서버에서 프로시저나 함수를 호출할 수 있도록하는 통신 프로토콜
Client ---------호출할 함수 이름 + 전달될 매개변수--------> Server
Client <----------------------결과---------------------- Server(요청 수신, 함수 실행)
- 분산 시스템 구축에 사용(시스템의 다른 구성요소는 다른 시스템이나 다른 위치에 있음)
- 개발자는 네트워크 통신의 복잡성을 숨기고, app의 논리에 집중할 수 있게 됨
- 구현: gRPC, Apache Thrift, XML-RPC, JSON-RPC 등
직렬화 형식 차이에 따라 JSON-RPC, gRPC로 나뉜다
JSON-RPC
- 텍스트 기반, 사람이 읽고 파싱하기 쉬운 JSON 형식 사용
- 단방향 스트리밍만 지원
gRPC
- google에서 개발, google의 프로토콜 버퍼(proto buf) 직렬화 형식으로 작동하도록 설계됨
- 기존 RPC보다 더 빠르고, 효율적, 최신 프로그래밍 언어를 더 잘 지원한다
- HTTP/2 위에 구축, 이진 인코딩 방식 사용 => 메세지 크기, 네트워크 대기 시간 줄어듦
- RPC와 다르게 양방향 스트리밍 지원
- MSA에 적합
내가 헷갈렸던 개념 HTTP-RPC(RPC over HTTP)
-> HTTP, RPC 다 7계층(Application Layer)에서 동작하는데 HTTP의 대안이 RPC가 아니었던 건가? 하는 의문이 있었음
-> 굳이 하나의 프로토콜로 동작해야한다는 생각을 버림,,,
대부분 HTTP-RPC로 동작(gRPC, JSON-RPC, Apache Thrift 등)
RPC는 요청이 HTTP 요청으로 전송되고 응답이 다시 HTTP 응답으로 전송되는 매커니즘으로 HTTP를 이용할 수 있음
(HTTP를 전송 프로토콜로 사용해 RPC 구현)
'Own > Memo' 카테고리의 다른 글
| OAuth 와 OpenID (0) | 2023.07.31 |
|---|
API
Application Programming Interface
독립된 소프트웨어 응용프로그램(app)이 서로 통신할 수 있도록 하는 일련의 프로토콜, 루틴, 도구
서로 다른 소프트웨어 구성요소가 서로 상호작용할 수 있는 방법 제공
(한 app에서 다른 app이 제공하는 데이터 또는 기능, 서비스에 접근할 수 있도록하는 매개체)
-> 다양한 기술과 시스템을 보다 쉽게 통합 가능
고려 사항: 수행하는 작업, 제공 or 사용할 데이터의 종류, 사용 방법, End Point(클라이언트가 API와 상호작용하는데 사용할 URL), API가 사용할 형식(JSON, XML 등), HTTP 메소드(POST, GET, PUT, DELETE), 클라이언트가 보낼 입력 매개변수, 반환할 출력 데이터, 문서화 등
API 구현 방법
1. REST(Representational State Transfer)
HTTP를 통한 리소스 지향 통신
- HTTP 메서드(GET, POST, PUT, DELETE 등)을 사용하여 리소스에 액세스하고 작업을 수행하는 API 설계에 널리 사용되는 아키텍처 스타일
- 상태 비저장(stateless), 요청-응답 모델(request-response)
- 널리 사용되고 문서화가 잘되어있어 다른 시스템과 쉽게 통합하여 구현 가능
2. SOAP(Simple Object Access Protocol)
- XML을 사용해 시스템 간에 데이터를 전송하는 프로토콜
- SOAP API는 표준화된 데이터 교환 방법을 제공
3. GraphQL
- 클라이언트가 고정된 데이터 집합을 반환하는 대신 필요한 정확한 데이터를 지정할 수 있도록 하는 API용 쿼리 언어
- GraphQL API는 특히 복잡한 구조의 데이터에 액세스하는 보다 효율적이고 유연한 방법 제공
4. RPC(Remote Procedure Call)
서버에서 원격 기능을 호출하는 방법
- 클라이언트가 원격 서버에서 메서드를 호출하고 결과를 받을 수 있도록 하는 프로토콜
- RPC API를 사용하여 간단하고 효율적인 방식으로 원격 서비스 또는 기능에 대한 액세스 제공 가능
- 클라이언트, 서버가 미리 잘 알려져 있고, 미리 정의된 상호작용 기능 집합이 있는, 밀접하게 연결된 시스템에서 사용 가능
- XML, JSON, 바이너리를 비롯한 여러 인코딩 형식 지원
5. WebSocket
실시간 양방향 통신
- 클라이언트와 서버 간의 양방향 통신 채널을 제공하여 클라이언트에 실시간 업데이트 및 알림 보낼 수 있음
- 빈번한 polling, 응답-요청 주기 X -> 즉각적이고 지속적인 데이터 교환 허용하는 영구연결 제공 + StateFul
- 실시간 app 구축, 푸시 알람, 대화형, 실시간 업데이트 등에서 사용
RPC 란?
- 클라이언트 app이 마치 로컬 함수인 것 처럼 원격 서버에서 프로시저나 함수를 호출할 수 있도록하는 통신 프로토콜
Client ---------호출할 함수 이름 + 전달될 매개변수--------> Server
Client <----------------------결과---------------------- Server(요청 수신, 함수 실행)
- 분산 시스템 구축에 사용(시스템의 다른 구성요소는 다른 시스템이나 다른 위치에 있음)
- 개발자는 네트워크 통신의 복잡성을 숨기고, app의 논리에 집중할 수 있게 됨
- 구현: gRPC, Apache Thrift, XML-RPC, JSON-RPC 등
직렬화 형식 차이에 따라 JSON-RPC, gRPC로 나뉜다
JSON-RPC
- 텍스트 기반, 사람이 읽고 파싱하기 쉬운 JSON 형식 사용
- 단방향 스트리밍만 지원
gRPC
- google에서 개발, google의 프로토콜 버퍼(proto buf) 직렬화 형식으로 작동하도록 설계됨
- 기존 RPC보다 더 빠르고, 효율적, 최신 프로그래밍 언어를 더 잘 지원한다
- HTTP/2 위에 구축, 이진 인코딩 방식 사용 => 메세지 크기, 네트워크 대기 시간 줄어듦
- RPC와 다르게 양방향 스트리밍 지원
- MSA에 적합
내가 헷갈렸던 개념 HTTP-RPC(RPC over HTTP)
-> HTTP, RPC 다 7계층(Application Layer)에서 동작하는데 HTTP의 대안이 RPC가 아니었던 건가? 하는 의문이 있었음
-> 굳이 하나의 프로토콜로 동작해야한다는 생각을 버림,,,
대부분 HTTP-RPC로 동작(gRPC, JSON-RPC, Apache Thrift 등)
RPC는 요청이 HTTP 요청으로 전송되고 응답이 다시 HTTP 응답으로 전송되는 매커니즘으로 HTTP를 이용할 수 있음
(HTTP를 전송 프로토콜로 사용해 RPC 구현)
'Own > Memo' 카테고리의 다른 글
| OAuth 와 OpenID (0) | 2023.07.31 |
|---|
