effetive typescript "Item 35 API와 명세를 보고 타입만들기" 를 읽다가 그래프 ql이 나왔는데 이름만 들어봤지 무엇인지 몰라서 이를 공부하다가 API와 비교하기위해 API도 정확하게 알고있는게 아니라 정리를 하게 되었다.
1. API란?
API라는 용어는 "Application Programming Interface"를 의미합니다.
API는 정의 및 프로토콜 집합을 사용하여 두 소프트웨어 구성 요소가 서로 통신할 수 있게 하는 메커니즘입니다.
조금 더 쉽게 설명해보자면 API를 레스토랑의 메뉴판이라고 생각하면 편합니다.
메뉴판에는 각 요리에 대한 설명과 함께 주문할 수 있는 요리 목록이 제공됩니다.
원하는 메뉴 항목을 주문하면 레스토랑의 주방에서 작업을 수행하고 완성된 요리를 제공합니다.
우리가 직접 요리에 들어가는 재료를 구하러 부산, 제주도, 강원도, 목포등을 갈 필요없고 그 재료를 보관할 냉장고등이 필요없으며 가스,수도, 전기 시설을 설치할 필요도 없고 조리 도구를 따로 구매하여 이 모든 과정을 할 필요가 없습니다.
우리는 단순히 이 요리 주문할게요 하면 일정시간이 지난후 그 요리가 완성되어 내 앞으로 전달됩니다.
이게 바로 API라고 생각하시면 됩니다.
가장 많이사용되는 API중 하나인"날씨 API"를 통해 이해해봅시다.
우리가 만약 API에게 xx지역 날씨정보를 달라고 한다면 아래와 같은 데이터를 제공해줍니다.
우리가 직접 그 지역에가서 온도를 측정하고 바람을 측정하고 구름의 정도를 측정할 필요없이 API에게 요청하면 이렇게 데이터를 바로 가져다 줍니다.
만약 사용자가 xx지역 온도 버튼을 누르면 API에게 xx 지역 날씨정보를 요청하고 API가 xx지역 날씨정보를 주면 그 중에서 온도만 사용자에게 보여주도록 만들면 됩니다.
그렇기에 개발자들은 API를 통해 플랫폼의 구현을 활용하여 핵심 작업을 수행함으로써 시간을 절약할 수 있습니다.
이는 개발자가 생성해야 하는 코드의 양을 줄이는 데 도움이 디ㅗ며 동일한 플랫폼의 앱 간에 더 많은 일관성을 생성하는 데에도 도움이 됩니다.
API는 하드웨어 및 소프트웨어 리소스에 대한 액세스를 제어할 수 있습니다.
2. API는 어떻게 작동할까?
API 아키텍처는 일반적으로 클라이언트와 서버 측면에서 설명됩니다.
요청을 보내는 애플리케이션을 클라이언트라고 하고 응답을 보내는 애플리케이션을 서버라고 합니다.
예를 들면 기상청의 날씨 데이터베이스는 서버이고 모바일 앱은 클라이언트 입니다.
API가 생성된 시기와 이유에 따라 API는 네 가지 방식으로 작동할 수 있습니다.
- SOAP API
- 이 API는 단순 객체 접근 프로토콜을 사용합니다. 클라이언트와 서버는 XML을 사용하여 메시지를 교환합니다.
- 과거에 더 많이 사용되었으며 유연성이 떨어지는 API입니다.
- RPC API
- 이 API를 원격 프로시저 호출이라고 합니다.
- 클라이언트 서버에서 함수나 프로시저를 완료하면 서버가 출력을 클라이언트로 다시 전송합니다.
- Websocket API
- Websocket API는 JSON객체를 사용하여 데이터를 전달하는 또 다른 최신 웹 API개발입니다.
- WebSocket API는 클라이언트 앱과 서버 간의 양방향 통신을 지원합니다.
- 서버가 연결된 클라이언트에 콜백 메시지를 전송할 수 있어 REST API보다 효율적입니다.
- REST API
- 오늘날 웹에서 볼 수 있는 가장 많이 사용되고 유연한 API입니다.
- 클라이언트가 서버에 요청을 데이터로 전송합니다.
- 서버가 이 클라이언트 입력을 사용하여 내부 함수를 시작하고 출력 데이터를 다시 클라이언트에 반환합니다.
이 네 가지 방식중에 REST API를 가장 많이 사용함으로 REST API에 대해 자세히 알아보겠습니다.
3. REST API란 ?
1) REST 란?
REST(Representational State Transfer)
- 자원을 이름(자원의 표현)으로 구분하여 해당 자원의 상태(정보)를 주고 받는 모든 것을 의미한다.
- 즉 자원(resource)의 표현(representation)에 의한 상태전달
- 자원(resource) : 해당 소프트웨어가 관리하는 모든것
- ex) 문서, 그림, 데이터, 해당 소프트웨어 자체 등
- 자원의 표현 : 그 자원을 표현하기 위한 이름
- ex) DB의 학생 정보가 자원일 때, 'students'를 자원의 표현으로 정한다.
- 상태(정보) 전달
- 데이터가 요청되어지는 시점에서 자원의 상태(정보)를 전달한다.
- JSON 혹은 XML를 통해 데이터를 주고 받는 것이 일반적이다.
- 자원(resource) : 해당 소프트웨어가 관리하는 모든것
- 즉 자원(resource)의 표현(representation)에 의한 상태전달
- www과 같은 분산 하이퍼미디어 시스템을 위한 소프트웨어 개발 아키텍처의 한 형식
- REST는 기본적으로 웹의 기존 기술과 HTTP 프로토콜을 그대로 활용하기 때문에 웹의 장점을 최대한 활용할 수 있는 아키텍처 스타일이다.
- REST는 네트워크 상에서 cClient와 Server 사이의 통신 방식 중 하나이다.
더 깊게 들어가면 REST란 HTTP URI(Uniform Resource Identifier)를 통해 자원(Resource)을 명시하고, HTTP Method(POST, GET, PUT, DELETE)를 통해 해당 자원에 대한 CRUD Operation을 적용하는 것을 의미한다.
REST 구성 요소
1. 자원(Resource) : URI
- 모든 자원에 고유한 ID가 존재하고, 이 자원은 Server에 존재한다.
- 자원을 구별하는 ID는 '/groups/:group)id'와 같은 HTTP URI 다.
2. 행위(Verb): HTTP Method
- HTTP 프로토콜의 Method를 사용한다.
- HTTP 프로토콜은 GET, POST, PUT, DELETE 와 같은 메서드를 제공한다.
3. 표현(Representation of Resource)
- Client가 자원의 상태(정보)에 대한 조작을 요청하면 Server는 이에 적절한 응답을 보낸다.
- REST에서 하나의 자원은 JSON,XML,TEXT,RSS등 여러 형태의 응답으로 나태내어 질 수 있다.
- JSON 혹은 XML를 통해 데이터를 주고 받는 것이 일반적이다.
2) REST API란?
REST API의 정의
- REST 기반으로 서비스 API를 구현한 것
- 최근 OpenAPI(누구나 사용할 수 있도록 공개된 API: 구글 맵, 공공 데이터 등), 마이크로 서비스(하나의 큰 애플리케이션을 여러 개의 작은 애플리케이션으로 쪼개어 변경과 조합이 가능하도록 만든 아키텍처) 등을 제공하는 업체 대부분은 REST API를 제공한다.
REST API의 특징
- 사내 시스템들도 REST 기반으로 시스템을 분산해 확장성과 재사용성을 높여 유지보수 및 운용을 편리하게 할 수 있다.
- REST는 HTTP 표준을 기반으로 구현하므로, HTTP를 지원하는 프로그램 언어로 클라이언트, 서버를 구현할 수 있다.
- 즉, REST API를 제작하면 델파이 클라이언트 뿐 아니라, 자바, C#, 웹 등을 이용해 클라이언트를 제작할 수 있다.
REST API의 주요 구성 요소
- 클라이언트 : 통신을 시작하는 사용자 측(장치에서) 실행되는 클라이언트 또는 프로그램입니다.
- 서버 - 기능 및 데이터에 대한 액세스로 API를 사용하는 서버
- 리소스 - 서버가 클라이언트로 전송하는 모든 콘텐츠(비디오, 텍스트, 그림)
3) REST API 작동 방식
REST API는 HTTP 요청을 통해 통신하여 데이터 생성, 읽기, 업데이트 및 삭제 기능을 완료합니다.
이를 CRUD 작업이라고도 합니다. REST는 요청된 리소스에 대한 정보를 제공하고 네 가지 방법을 사용하여 리소스로 수행할 작업을 설명합니다.
- POST - resource 생성
- GET - resource 얻기
- PUT - resource 업데이트
- DELETE - resource 삭제
영화 사이트로 예를 들어보겠습니다.
4) resource
resource는 정보 추상화적인 REST API의 중요한 개념입니다. 문서, 이미지, 임시 서비스 등 모든 정보가 될 수 있습니다.
정보는 JSON,HTML,XLT,Python 또는 일반 텍스트와 같은 다양한 형식으로 클라이언트에 전달할 수 있습니다.
가장 인기 있고 사용되는 것은 JSON입니다. 왜냐하면 사람과 기계가 읽을 수 있고 언어에 구애받지 않기 때문입니다.
resource에 액세스 하려면 클라이언트가 요청을 해야합니다. 수신 후 서버는 resource에 대한 인코딩된 데이터로 응답을 생성합니다.
요청 구조에는 HTTP method(앞에서 언급한 CRUD), endpoint, headers 그리고 body가 주요 구성 요소에 포함됩니다.
- HTTP
- method는 resource로 수행해야 하는 작업을 설명합니다. (바로 위에서 설명한 POST, GET, PUT, DELETE)
- Endpoint
- endpoint 에는 resource를 찾을 수 있는 방법과 위치를 나타내는 URI(Uniform Resource Identifier)가 포함됩니다.
- URL 또는 Uniform Resource Location은 전체 웹 주소를 나타내는 가장 일반적인URI 유형입니다.
- Header
- Header에는 클라이언트 및 서버와 관련된 데이터가 포함횝니다. header에는 API키, 이름, 서버가 설치된 컴퓨터에 속한 IP주소 및 응답 형식에 대한 정보와 같은 인증 데이터가 포함됩니다.
- Body
- body는 추가하려는 데이터와 같은 추가 정보를 서버에 보내는데 사용합니다.
3) REST API의 보안
REST API는 HTTP를 사용하며 TLS(Transport Layer Security) 암호화를 지원합니다. TLS는 인터넷 연결을 비공개로 유지하고 두 시스템(서버와 서버 또는 서버와 클라이언트) 간에 전송된 데이터가 암호화되어 수정되지 않았는지 확인하는 표준입니다. 이는 쇼핑 웹 사이트에서 사용자의 신용카드 정보를 노출시키려는 해커가 사용자의 데이터를 읽거나 변경할 수도 없다는 것을 뜻합니다. URL이 “HTTPS(Hyper Text Transfer Protocol Secure)”로 시작되는 경우, 웹사이트가 TLS로 보호되는지 알 수 있습니다.
REST API는 웹 브라우저를 통해 데이터를 보다 쉽게 전송할 수 있는 파일 형식인 JSON(JavaScript Object Notation)을 사용합니다. REST API는 HTTP와 JSON을 사용함으로써 데이터를 저장하거나 다시 패키징할 필요가 없으므로 SOAP API보다 훨씬 속도가 빠릅니다.
API 보안을 강화할 수 있는 일반적인 방법
- 토근을 사용하기
- 신뢰할 수 잇는 여러 Identity를 설정한 후 해당 Identity에 할당된 토큰을 사용하여 서비스 및 리소스에 대한 액세스를 제어합니다.
- 암호화 및 서명을 사용하기
- TLS와 같은 방법을 사용하여 데이터를 암호화합니다.
- 올바른 사용자 외에 다른 누구도 내 데이터의 암호를 해제하고 수정할 수 없도록 서명을 요구합니다.
- 할당량 및 제한을 사용하기
- API 호출 빈도에 대한 할당량을 설정하고 사용 기록을 추적합니다. API호출이 증가할 수록 이것이 악용되고 있다는 의미일 수 있습니다. API호출 무한 반복과 같은 프로그래밍 상의 실수일 수도 있습니다. 제한 룰을 만들어 급격한 트래픽 증가와 DoS공격으로부터 API를 보호합니다.
- API 게이트웨이를 사용하기
- API게이트웨이는 주요 API트래픽 실행 지점역할을 합니다. 안전한 게이트웨이를 이용하여 트래픽을 인증하고 API 사용방식을 제어 및 분석할 수 있습니다.
4. API의 장단점
1) API의 장점
데이터 접속의 표준화와 편의성 그리고 시간 세이브
위의 접근 방식에 따른 public API와 partner API 등의 종류들에서 알아봤듯이 API는 모든 접속을 표준화하기 때문에 디바이스/운영체제 등과 상관없이 조건만 맞다면, 말하자면 범용 플러그처럼 누구나 동일한 액세스를 약속한다. 또 조직에서 애플리케이션을 개발할 때 기능적 API를 사용하면, 필요한 기본 기능들(인증, 통신, 지불 처리 및 위치 확인 등)을 매번 자가 개발/업데이트할 필요 없이 손쉽게 이용할 수 있는 장점이 있다. 즉, 더 이상 수레바퀴를 만들 때마다 매번 재발명할 필요가 없다.
자동화와 확장성
API를 통한 CRUD 처리에 따라 관련 데이터와 콘텐츠가 자동으로 생성되고 사용자의 환경에 맞춰서 정보가 전달 되어 개발 워크플로우가 간소화되고 애플리케이션 확장이 다소 용이하다. 예를 들자면 API를 활용한 웹 사이트 분석, 프로젝트 및 팀 관리 도구, 온라인 결제 시스템, 기타 여러 운영 설루션에 필요한 애플리케이션을 다소 쉽게 작성 가능하다.
파트너 또는 일반 사용자에게 API를 공개하면 이점을 얻을 수 있다
API를 만들어 제 3자에게 제공한다고 했을 때 유료로 한다면 새로운 수익 채널을 확보할 수 있습니다.
물론 무료로도 할 수 있습니다. 또한 이렇게 제3자에게 공개하면 외부 개발을 활용하고 협업을 수행하여 오픈 혁신을 촉진하거나 효율성을 높이고 브랜드 기업은 인지도를 확보할 수 있습니다.
2) API의 단점
보안성과 HTTP 방식의 제한
가장 주목할 것은 API의 단일 진입점인 API 게이트웨이는 해커의 타겟 대상이 될 수 있다는 점이다. 한마디로 API의 장점– 평범한 HTTP 메서드를 사용하여 액세스 할 수 있다는 점–이, 보안성에 관해서는 반면 크나큰 단점이 된다. 이 때문에 다른 일반적 인터넷 기반 리소스와 마찬가지로 메시지 가로채기 공격(man-in-the-middle), CSRF(Cross-Site Request Forgery) 공격, 크로스 사이트 스크립팅(Cross Site Scripting, XSS), SQL 삽입 공격(SQL injection), DDoS(Denial-of-service attack) 공격 (서비스 거부 공격) 등에 취약한 것이 사실이다. 또한 이러한 HTTP method는 메서드 형태가 다소 제한적이라는 문제점이 있다.
표준의 부재와 개발 비용
REST API의 설계에 있어 가장 큰 단점이라고 할 수 있는 점이 공식화된 표준이 존재하지 않는다는 점이다. 그러므로 관리가 어렵고 실제로 API 기능을 구현하고 제공하려면 개발 시간, 지속적인 유지 관리 요구 사항 및 지원 제공 측면에서 비용이 많이 들 수 있다. 또한 기존 API의 기능을 확장하려고 할 때 광범위한 프로그래밍 지식이 필요하다.
resource
https://www.redhat.com/ko/topics/api/what-are-application-programming-interfaces
https://www.howtogeek.com/343877/what-is-an-api/
https://aws.amazon.com/ko/what-is/api/
https://appmaster.io/blog/what-rest-api-and-how-it-differs-other-types
정말 잘 쓴 글 https://gmlwjd9405.github.io/2018/09/21/rest-and-restful.html
https://www.redhat.com/ko/topics/security/api-security#%EA%B0%9C%EC%9A%94
