API
- 추가적으로 다양한 기능들의 통신으로 결과를 나타내어 보여줄 때 원하는 형식, 타입, 내용에 대해서만 데이터를 표현할 수 있는 특징이 있음
- 원하는 타입의 정보만 표현할 수 있다는 의미여서 보안성에도 연관이 있음
API의 특징
질문 1> API의 대표적인 특징 - 각 특징을 간단하게 설명
- Automation tasks : manual tasks(수동 방식)를 automatically 와 programmatically. 방식으로 수행하는 script를 build함.
- Data integration : application program은 다른 application program에서 제공하는 data를 사용하거나 react 할 수 있다.
- Functionality : application은 다른 application의 기능을 해당 제품에 통합할 수 있다.
API의 design styles
질문 2> API 디자인 패턴 별 아래의 특징 정리
-
어떤 경우에 각각의 방식이 사용되는지
-
각 방식의 이점
-
각 방식 별 클라이언트의 처리 방식
-
Synchronous APIs
쉽게 말해 선착순(순차) 방식이 동기식 process.
Synchronous APIs는 request에 직접 응답하며 일반적으로 data를 즉시 제공함.
Data가 database나 internal memory에 저장되어 있는 경우와 같이 request data를 쉽게 사용할 수 있는 경우 동기식으로 API가 설계됨. Server는 이 데이터를 즉시 가져와 즉시 응답 가능함 -
장점 및 단점
Application이 data를 즉시 수신할 수 있음. API가 올바르게 설계되면 모든 일이 빠르게 진행되므로 어플리케이션의 성능이 향상됨. BUT!! 올바르게 설계되지 않으면 application이 response를 기다려야 함으로 API request에 bottleneck 현상이 발생함. -
Client side Processing : API를 요청하는 application은 추가 코드 실행 작업을 수행하기 전 response를 기다려야 함.
-
Asynchronous APIs
쉽게 말해서 요청과 응답이 따로 이루어짐.
Request가 수신되었음을 나타내는 response 제공 -> but 해당 response엔 실제 데이터가 없음. Server는 시간이 걸릴 수 있는 request를 처리하고 그 후 data와 함께 알림을 보냄(혹은 call back trigger). 그 후 client는 return된 data에 대해 조치를 취할 수 있음
API는 일반적으로 request가 server가 처리하는데 시간이 걸리는 작업이거나 data를 쉽게 사용할 수 없는 경우 비동기식으로 설계됨. server가 data를 가져오기 위해 원격 서비스에 요청해야 하는 경우 클라이언트로 다시 보내기 위해 데이터를 즉시 수신할 것이라고 보장할 수 없음.
비동기식 API라고 해서 반드시 클라이언트가 데이터를 즉시 가져오지 않는 것은 아님!
But data에 대한 즉각적인 request가 보장되지 않음! -
장점 및 단점
Server가 request를 처리하는데 걸리는 시간 동안 application이 차단되지 않고 계속 실행될 수 있음. 결과적으로 application은 multi tasking을 수행하고 다른 요청을 할 수 O. -> 더 나은 성능!
But!! Asynchronous call을 불필요하게 과도하게 사용하면 성능이 낮아짐. -
Client side Process : Server 측에서 API를 설계하면 클라이언트 측에서 수행하려는 task가 정의됨. 또한 이런 알림을 수신하고 수신을 처리하기 위해 listener 혹은 call back mechanism을 설정할 수 있음. 또한 application program의 디자인에 따라 클라이언트는 처리 순서를 유지하기 위해 요청을 저장할 대기열이 필요할 수도 있음. 다른 API 디자인은 client가 주어진 request의 상태와 진행상황을 알아내기 위한 Polling mechanism을 필요로 함.
API Arcitectural Styles
질문 3 > APU Arcitectural styles - 각 스타일 별 특징을 설명 (REST 방식을 제외한 두가지 방식은 간단하게 설명)
-
RPC(Remote Procedure Call)
코딩 없이 다른 주소 공간에서 Application program (client)이 다른 application program (server)에 대한 procedure나 함수 call을 할 수 있도록 하는 request-response model.
분산 네트워크 환경에서 더 편하게 프로그래밍 하기 위해 등장
Client는 server에 synchronous request를 만들고 server가 request를 처리하는 동안 차단됨. Server가 request를 완료하면 client에 response를 보내 process 차단을 해제함 -> asynchronous request에는 적용 X -
SOAP(Simple Objects Access Protocol) – PRC 구현의 한 예임.
envelope/header/body/Fault로 구성되는 메시징 프로토콜. 다른 플랫폼에 있거나 다른 프로그래밍 언어로 구축된 응용프로그램 간의 통신에 사용됨.
1) Independent 독립적
2) Extensible 확장 가능
3) Neutral 중립적 – 모든 프로토콜(HTTP, SMTP, TCP, UDP 등)에서 사용 가능 -
REST (Representational State Transfer)
resource를 이름으로 구분해 해당 resource의 state를 주고 받는 것.
아키텍쳐 내의 elements에 적용되는 6가지 제약 조건 (특징)
1) Client-Server
일관적인 interface로 분리되어 있어야 함. 따라서 서로 간의 의존성 줄어듬.
Resource를 가진 쪽이 server, resource를 요청하는 쪽이 client
흔히 말하는 백앤드, 프론트앤드를 나누는 기준.
2) Stateless
각 request 간 client의 context가 server에 저장되어서는 안됨
HTTP protocol의 장점을 극대화하기 위한 방법
세션 정보나 쿠키 정보를 별도로 저장하고 관리 X -> API server는 client의 request만을 단순 처리하면 됨 -> 서비스 자유도 높아짐, server에서 불필요한 정보 관리하지 않아 구현이 단순하다는 장점!
3) Cache (캐시 처리 가능)
서버의 response는 response의 cache 여부를 명시해야 함. Cache 가능한 경우 클라이언트는 이후 요청에 대한 응답의 data를 사용할 수 있음.
잘 관리되는 caching은 클라이언트-서버 간 상호작용을 부분적 혹은 완전하게 제거하여 scalability와 성능을 향상시킴.
웹 표준 HTTP protocol을 그대로 사용하므로 웹에서 사용하는 기존 인프라를 그대로 활용 가능
4) Uniform Interface 균일한 인터페이스
Resource(URI)에 대한 요청을 통일되고, 한정적으로 수행하는 아키텍처 스타일
1) dentification of resources 리소스 식별
2) Manipulation of resources through representations
3) Self-descriptive messages 자체 설명 메시지
4) Hypermedia as the engine of application state : 서버에서 보낸 데이터는 클라이언트가 리소스에 대한 추가 정보에 액세스할 수 있는 추가 작업과 리소스가 포함되어야 함.
5) Layered System
시스템은 각 계층이 상위 계층에만 서비스를 제공하는 계층으로 구성됨. 즉 아래 계층의 서비스를 소비함!
즉, 계층화된 시스템 아키텍처를 사용하여 각 구성들 간의 계층을 마음대로 상호작용 할 수 없도록 제한 함으로 써 Interface를 일원화할 수 있음
6) Code-On-Demand – 선택사항임
서버가 네트워크를 통해 클라이언트에 전달한 javascript 등과 같은 프로그램들은 그 자체로 실행이 될 수 있어야 한다. 이것은 사전 구현에 필요한 기능의 수를 줄임으로써 클라이언트를 단순화한다.
즉, 평소에는 정적인 데이터를 xml 또는 json에 담아서 client로 보내고 client가 이걸 가공함. 하지만 code on demand라는 것은 client에 보내는 데이터를 바로 실행 가능한 코드를 보내서 이것을 Client에서 실행하는 것을 말한다
REST API는 HTTP를 통해 통신하기 때문에 HTTP 프로토콜과 동일한 개념을 사용함
HTTP requests/responses
HTTP verbs
HTTP status codes
HTTP headers/body
- REST API request : REST 원칙을 따르는 HTTP request -> 이러한 request는 application program (client)이 server에 기능을 수행하도록 요청하는 방법
- REST API request의 주요 components
1) Uniform Resource Identifier (URI)
클라이언트가 조작하려는 리소스를 식별
Scheme / Authority / Path / Query
2) HTTP Method
3) Header
추가 정보! Request headers/ Entity headers 가 있음
4) Body
클라이언트가 조작하려는 리소스와 관련된 데이터가 포함
API -Rate limits
질문 4 > rate limits에 대해 설명
- APU 속도 제한의 목적
웹 서비스가 정의된 시간 단위당 사용자 또는 애플리케이션이 만들 수 있는 요청 수를 제어하고자..
1) X-RateLimit-Limit : 지정된 시간 단위에 할 수 있는 최대 요청 수
2) X-RateLimit-Remaining : 현재 비율 제한 창에서 요청자가 할 수 있는 남은 요청 수
3) X-RateLimit-Reset : 속도 제한 창이 재설정되는 시간
API - Webhook
질문 5> Webhook에 대해 설명
Webhook : 웹 애플리케이션이 서로 통신할 수 있는 방법 중 하나.
주어진 ‘이벤트’가 발생할 때마다 한 응용 프로그램에서 다른 응용 프로그램으로 실시간 데이터를 보낼 수 있음! 지정된 URL에 대한 HTTP callback 혹은 HTTP POST이다.
API - 4.5.5 / 4.9.2 Labs
질문 6 > 각 랩을 진행하며 새로이 알게된 내용, 실습 진행 시 느낀 주의사항
4.5.5 : Explore Rest APIs with API Simulator and Postman
- API의 구조와 사용법에 대해 알게 되었다. GET, POST 등 명령어를 익혔고, Postman이라는 프로그램으로 API를 만들고, 사용해보고, request, response 등을 받아보았다. Postman 프로그램을 사용하는 법이 엄청 자세히 나와있지는 않아(버튼이 어디에 있는지를 헷갈리게 기재되어있어 어려웠음) 그 프로그램 사용법에서 어려움이 있었지만 API의 사용법에 대해선 웹페이지에서 해본 후 프로그램으로 실행해보니 더 자세히 알 수 있었다.
4.9.2 : Integrate a REST API in a Python Application
- JSON data의 구조에 대해 익힐 수 있었다. API request를 생성하는 법을 배우고, vs code 프로그램을 사용해 다양한 파이썬 문법을 통해 출력을 해보았다. 또한 API가 key와 value pair로 이루어져 있음을 확인할 수 있었고, JSON 기반의 data를 처리하는 법을 배울 수 있었다. url을 통해 api를 가져오고 이를 사용해 다양한 application을 테스트 해보았다. 나아가 402, 611 등의 서버 (오류) 메시지에 대해 테스트해보고 익힐 수 있었다.
