참고
API (Application Programming Interface)
NOTE
클라이언트 - 서버가 통신을 하기위한 규칙을 API라고 한다!
API의 종류는 굉장히 많다.
•
ex) 온라인으로 전화주문을 한다.
◦
웹에 연결된 사이트로 이동하면 쿼리에 대한 정보가 서버로 전송된다.
◦
서버는 정보를 가져와 분석하고 필요한 조치를 취한후 홤녀에 표시된 세부 정보로 회신한다.
•
API는 이러한 클라리언트 요청을 수행하는 방법과 다른 프로그램으로 보낼 수 있는 쿼리의 종류를 말한다.
◦
ex) gRPC, REST, GraphQL
•
API의 가장 좋은 패턴
◦
API 페이지네이션
◦
비동기 기능
◦
버저닝 API
RPC(Remote Procedure Calls)
NOTE
미리 정의된 형식을 사용하여 원격 서버에서 서비스를 실행하고 동일한 형식으로 응답을 받을 수 있도록하는 웹 아키텍쳐!
이해가 잘안가면 해당 영상을 한번보자(nodeJS)로 실제 사용하는걸 보여줌
쉽게 설명하면 다른 서버의 메소드를 호출하고 결과값을 가져온다.
•
원격에 위치한 프로그램을 로컬에 있는 프로그램 처럼 사용할 수 있다.
•
개발자는 network 통신에 관련된 작업은 신경쓰지 않아도 된다.
개념
•
Stub
◦
클라이언트 보조 객체
◦
클라이언트가 스텁의 비즈니스 메소드를 호출하면, 호출된 메소드명과 매개변수로 전달된 값들이 스트림 형태로 서버에 전달된다.
•
Skleton
◦
서버 보조 객체
◦
스트림을 분석해 어떤 메소드가 요청되었는지 파악하고 결과값 전달
장점/단점
•
장점
◦
고유 프로그램 개발에 집중할 수 있다.
◦
프로세스간 통신을 비교적 쉽게 구현할 수 있다.
◦
여러 언어를 지원하기에 쉽게 확장이 가능하다.
•
단점
◦
호출 실행과 반환 시간이 보장되지 않는다.
사용사례
•
마이크로 서비스에 적합하다.(외부 서버에는 비적합)
REST(REpresentational State Tranfer)
NOTE
사용자가 JSON/XML 통신을 통해 백엔드 정보에 엑세스할 수 있는 client-server 아키텍쳐를 의미한다.
URL에 쿼리를 제출하여, JSON/XML(리소스)를 받는다.
•
HTTP 프로토콜(1.1)을 기반으로 한다.
•
리소스(자원)은 URI로 표현하며, 고유해야 한다.
•
처리 결과를 status code로 사용한다.
•
리소스 상태는 HTTP Method를 활용해 구분한다.
특징
•
무상태성
◦
클라이언트의 컨텍스트를 서버쪽에 유지하지 않는다.
◦
각 API 서버는 들어오는 요청만 메세지로 처리한다.
•
캐쉬가능
◦
HTTP 프로토콜 표준에서 사용하는 태그를 사용하면 구현할 수 있다.
▪
ex) client가 HTTP GET을 Last-Modified값과 함께 보내면, 컨텐츠 변화가 없을 때 304 NOT Modified를 리턴하고 client자체에 저장된 값을 사용한다.
◦
네트워크 응답시간과 성능, 서버의 자원 사용률을 향상시킬 수 있다.
사용 사례
•
Public API
•
쿼리에 유연성이 필요하지 않은 리소스 기반 앱에 유용
•
RESTful API
◦
REST 원칙에 따라 설계된 API이다.
◦
REST는 웹의 장점을 최대한 활용할 수 있는 아키텍쳐 스타일로, HTTP 프로토콜을 기반으로 설계되었다.
◦
RESTful API는 이러한 REST원칙을 따른느 서비스를 말한다.
GraphQL
NOTE
기존 API에서는 하나의 View를 그리기위해 여러번 API를 호출해서 조합해야한다.
⇒ 이를 해결하기 위해 필요한 데이터를 한번에 가져오는 GraphQL을 사용!
필요한 데이터만 얻기위해, 클라이언트에서 사용할 Query Language를 제공한다.
RestAPI와 GraphQL을 비교한다. (한번의 호출로 다 불러옴)
•
HTTP 프로토콜(1.1)을 기반으로 한다.
•
리소스(자원)은 URI로 표현하며, 고유해야 한다.
•
처리 결과를 status code로 사용한다.
•
리소스 상태는 HTTP Method를 활용해 구분한다.
사용 사례
•
복잡한 시스템 및 마이크로 서비스
•
모바일 API