Api란 무엇일까요? Api 유형과 프로토콜
원문: Vinayak Singh, "What is an API? Its types and protocols used"
소개
가족끼리 레스토랑에 저녁을 먹으러 갔다고 상상해 보세요. 가족 모두 각자 선호하는 음식들을 먹고 싶을 것입니다. 주방에는 조리 기구가 있습니다. 그렇다고 매니저가 누군가 주방으로 가서 요리하도록 허락할까요? 절대 아닙니다! 대신 웨이터가 테이블로 와서 주문을 받고 주방장에게 간 후 시간이 지나면 주문한 음식을 가지고 돌아옵니다.
레스토랑 매니저는 부엌과 같은 특정 장소에 접근 권한이 없는 사람들을 허용하지 않습니다. 여기서 웨이터는 당신과 레스토랑 사이의 인터페이스 역할을 하는 것입니다. 이것이 소프트웨어 개발에서 API가 정확히 맡은 일입니다.
API(Application Programming Interface)는 관계없는 소프트웨어 제품을 다른 소프트웨어 서비스 및 데이터와 통합하고 상호작용 할 수 있게 해줍니다. 시스템 간 데이터 전송을 처리하는 중간 계층 역할을 하여 기업이 외부 타사 개발자, 비즈니스 파트너, 내부 부서에 애플리케이션 데이터와 기능을 개방할 수 있도록 합니다.
사용자는 사용자 인터페이스(UI)를 통해 시스템과 상호작용 합니다. 이와 비슷하게 API는 소프트웨어가 서로 명령을 실행하거나 서버로부터 데이터를 가져오거나 하는 등의 상호작용을 할 수 있도록 존재합니다.
API 동작 방식
API의 동작 방식을 이해하는 간단한 방법은 타사 결제 처리와 같은 예를 살펴보는 것입니다. 사용자가 이커머스 웹사이트에서 상품을 주문하고 있다고 합시다. 결제 방식 선택 페이지에서 "Paytm으로 결제" 또는 PayPal 등 기타 타사 시스템으로 결제하라는 메시지가 표시됩니다. 이 기능은 이제 API에 따라 좌우됩니다.
구매자가 결제 버튼을 누르면 API가 사용자 정보를 가져오기 위해 API 호출이 이루어집니다. 이 요청은 결제 서비스 측에서 요청의 유효성을 검사하기 위해 API의 URI(Uniform Resource Identifier)를 통해 처리됩니다.
타사 시스템은 화면에 정보를 표시하지 않고 사용자 계정 수준에서 모든 확인을 검증하고 수행합니다. 그 후 서버는 최초 요청 애플리케이션, 즉 여기서는 이커머스 플랫폼으로 응답을 다시 보냅니다.
데이터 전송은 API를 통해 발생하는 요청과 응답에 사용되는 서비스 유형, 프로토콜 및 형식에 따라 다르지만 사용자 인터페이스에서는 보이지 않고 사용자에게 표시되는 것은 하나의 서비스처럼 보이는 서로 다른 서비스 간의 원활한 연결뿐입니다.
API 또는 웹서비스 - 둘 사이의 혼동
W3C에 따르면 웹 서비스는 인터넷을 통해 기계 간 상호작용을 돕도록 설계된 소프트웨어 시스템이라고 합니다. 잠시만요. API와 비슷해 보이지 않나요?
두 용어는 같은 의미로 사용되지만 미세한 차이가 있습니다. 웹 서비스는 네트워크를 통해 사용할 수 있는 API의 한 유형입니다. 모든 웹 서비스는 API이지만 모든 API가 웹 서비스는 아닙니다.
API와 웹 서비스의 다른 점은 API는 양방향 통신을 허용하고 웹 애플리케이션을 통한 웹 서비스는 사용자가 웹 브라우저를 통해 상호작용 할 수 있는 방법이 단방향입니다. 웹 서비스에는 요청을 완료하기 위한 API가 있을 수 있습니다.
웹 서비스는 REST, SOAP, XML, RPC 같은 프로토콜 기반의 통신을 하지만 API는 어떠한 방식의 통신에서든 사용할 수 있습니다.
이 둘의 또 다른 중요한 차이점은 지원하는 형식입니다. 웹 서비스는 요청 및 응답을 위해 HTTP 프로토콜과 XML 메시지 교환 형식만 지원하는 반면 API는 통신을 위해 HTTP/HTTPS 프로토콜과 함께 XML 및 JSON 메시지 교환 형식을 모두 지원합니다.
API의 유형
"유형"이란 API의 사용 범위를 의미합니다. 웹 서비스에서 사용되는 API에는 네 가지 유형이 있습니다.
공개 API
오픈 API 또는 외부 API라고 불리기도 하는 공개 API는 다른 개발자 또는 기업이 사용할 수 있도록 공개된 API입니다. 이러한 API는 일반적으로 권한 부여 및 인증 수준이 낮거나 중간 정도입니다. 대부분의 공개 API는 무료로 사용할 수 있지만 일부 공개 API는 사용량에 따라 비용이 청구되며 요청 제한이 적용될 수도 있습니다.파트너 API
파트너 API는 B2B 활동을 처리하기 위해 만들어졌으며 모기업 외부의 개발자가 선택적으로 사용할 수 있도록 제공됩니다. 이러한 API는 권한 부여, 인증 및 보안에 더 강력한 규칙과 가이드라인을 적용합니다. 기업 조직은 전용 규칙이 정의된 파트너 API를 통해 외부 기업과 고객 데이터를 공유할 수도 있습니다. 다른 API는 사용되지 않습니다.비공개 API
비공개 API는 HR 부서와 급여 팀같이 조직 내에서 사용되는 API입니다. 기업 내부 시스템과 데이터를 연결하도록 만들어졌습니다. 보통 외부와 연결되어 있지 않기 때문에 이러한 API는 보안이 약하거나 아예 도입하지 않는 것을 선택할 수 있습니다. 그러나 상황은 변하고 있으며 기업들은 규정 준수 요구사항에 맞춰 강력한 보안을 도입하고 있습니다.복합 API
복합 API는 여러 API 요청을 하나의 호출로 결합하여 복잡한 문제에 대한 해결책을 구성합니다. 이렇게 하면 데이터가 절약되고 시스템에서 수행하는 API 호출 횟수가 줄어들어 애플리케이션이 효율적으로 작동합니다.
GraphQL은 모든 쿼리를 단일 엔드포인트로 통합하고 클라이언트가 요청하는 것을 정확하게 반환하여 오버 또는 언더 페칭을 방지하므로 복합 API의 한 예로 들 수 있습니다. 개발자는 요청하는 페이로드를 엄격하게 묶어야 하지만 API 호출 횟수가 줄어들어 시스템 속도가 빨라집니다.
API 프로토콜
모든 API는 개발자가 소프트웨어에 통합하기 위해 따라야 하는 일련의 규칙과 기술이 정의되어 있습니다. 이러한 규칙은 API를 구현하는 방법과 API를 사용하는 방법을 규정합니다. 이러한 규칙을 API 프로토콜이라 합니다. API 프로토콜은 허용된 명령어, 데이터 타입, 사용될 형식 등 다른 많은 것을 함께 정의합니다.
자주 사용되는 API 형식은 아래와 같습니다.
SOAP
SOAP(Simple Object Access Protocol)는 간단한 객체 접근 프로토콜을 의미합니다. 1998년에 시작되었지만 여전히 사용되고 있습니다. SOAP에서는 요청과 응답 메시지 교환 방식으로 XML만 사용합니다. SOAP는 본질적으로 고도로 구조화되어 있고 모든 XML 요청과 응답에 대해 표준 형식을 요구합니다.
REST
REST(Representational State Transfer)는 대표 상태 전송을 의미합니다. REST는 API를 설계하기 위한 '아키텍처 접근 방식'에 가깝습니다. 본질적으로 상태가 없는 방식으로 SOAP처럼 특정 형식의 메시지를 강제하지 않습니다. REST API 엔드포인트는 HTTP 메서드를 사용하여 리소스에 대한 CRUD(생성, 읽기, 갱신, 삭제) 작업을 실행하는 URL입니다. 이러한 HTTP 메서드는 GET, POST, PATCH, PUT, DELETE입니다. 서버에서 클라이언트로 리소스를 제공하는 데 중점을 둡니다.
RPC
RPC를 이해하려면 프로그램에서 특정 함수를 실행하면 네트워크를 통해 연결된 다른 컴퓨터에서 함수 호출을 트리거하는 것과 같다고 생각하면 됩니다. 다른 컴퓨터는 요청을 수신한 후 추가 처리에 사용할 수 있도록 응답을 시스템에 반환합니다.
일반인의 이해를 돕기 위해 사무실에서 일하고 있는데 어머니가 특별히 만든 쿠키를 받고 싶다고 가정해 보겠습니다. 어머니에게 좋아하는 쿠키 한 상자를 보내달라고 이메일을 보내면 됩니다. 이것이 RPC의 예입니다. 물론 아무나 RPC를 할 수 있는 것은 아닙니다. 권한 부여 및 인증에 대한 규칙이 있습니다. 이 경우 오직 가족만 맛있는 쿠키를 요청할 수 있습니다 :)
RPC(Remote Procedure Call)은 프로그래머가 원격 상호작용에 대한 세부 사항을 명시적으로 코딩하지 않고도 컴퓨터 프로그램이 다른 주소 공간 (일반적으로 공유 네트워크의 다른 컴퓨터)에서 서브루틴이나 프로시저를 실행할 수 있도록 하는 프로세스 간 통신 기술입니다. RPC는 REST보다 더 강력하지만 동시에 사용하기가 더 어렵습니다.
XML-RPC
XML-RPC 프로토콜은 데이터를 수신하기 위해 특정 XML 형식을 사용합니다. SOAP보다 오래되었지만 더 가볍고 간단하며 훨씬 적은 대역폭을 요구합니다.
JSON-RPC
이름에서 유추할 수 있듯이 데이터 수신을 위해 JSON 형식을 사용합니다
gRPC
구글에서 처음 개발한 후 오픈소스로 공개된 gRPC는 고성능 오픈소스 RPC 프레임워크입니다.
위의 프로토콜과 달리 gRPC는 개발자가 필요에 따라 서비스 간 통신을 가능하게 하는 자체 사용자 정의 기능을 정의할 수 있습니다. gRPC는 HTTP를 전송 계층으로 사용하고 인증 기능, 타임아웃, 흐름 제어 등과 같은 추가 기능을 제공합니다. 데이터는 프로토콜 버퍼(protobuffs)로 전송되는데 이는 언어와 플랫폼에 독립적인 메커니즘으로 데이터를 보다 직관적인 방식으로 구조화할 방법을 정의합니다.
프로토버프는 먼저 서비스 정의를 한 다음 서비스에서 사용할 데이터 구조를 정의하는 것으로 시작합니다. 이것은 protoc 컴파일러에 의해 컴파일되며 작업 중인 개발 언어의 기본 set 메서드와 함께 당신이 정의한 데이터 타입이 제공되는 전체 클래스를 생성합니다. 이제 이 클래스를 사용하여 API의 세부적인 작업을 구현할 수 있습니다.
GraphQL
지금은 메타로 사명이 바뀐 페이스북에서 개발된 GraphQL은 API 데이터를 원하는 형식으로 정의하는 질의 언어입니다. GraphQL은 개발자가 요청에 지정한 정확한 형식대로 서버에서 데이터를 질의하는 강타입 질의 언어입니다.
이 글은 여기까지입니다. 다음 글에서는 REST와 SOAP의 차이점에 대해 더 자세히 알아보겠습니다. 그런 다음 GraphQL의 기본 개념과 GraphQL 사용 방법을 이해하고 GraphQL, Postgres, JavaScript를 활용한 프로젝트를 설정하는 작업을 진행할 것입니다.
읽어주셔서 감사합니다. 이 글이 좋았다면 피드백을 주시면 매우 감사하겠습니다.
더 많은 글을 원한다면 제 블로그를 확인해 보세요!! ✌
