API(영어) 응용 프로그래밍 인터페이스) - 이것이 애플리케이션 프로그래밍 인터페이스입니다. 특정 애플리케이션이나 서비스의 API는 제3자 개발자가 이 서비스와 함께 작업하기 위해 자체 애플리케이션과 스크립트를 만들 수 있는 미리 만들어진 절차, 기능 및 변수 세트를 제공합니다.

API를 통해 작업할 때 애플리케이션은 생성된 프로그래밍 언어에 관계없이 서비스에 요청을 보내고 요청된 데이터가 포함된 응답을 받습니다.

제3자 서비스와 자체 애플리케이션을 사용하는 온라인 상점 소유자는 API를 통해 다음과 같은 액세스 기회를 갖습니다.

접수된 주문에 대한 정보

주문 정보 처리에 사용 가능한 작업(방법):

1. ID별 주문정보 선택
2. 필터로 주문정보 선택
3. 필터별 주문 수
4. 주문 생성
5. 주문 삭제
6. 주문 대량 삭제
7. 주문에 사용 가능한 모든 상태 선택
8. 주문 상태 업데이트
9. 주문에 설명 추가

가입자 정보

1. 구독자 추가
2. 구독자 삭제
3. 가입자 대량 삭제
4. 필터로 구독자 데이터 선택
5. 필터별 구독자 수

등록된 사용자에 대한 정보

구독자에 대한 정보 처리에 사용 가능한 작업(메서드):

1. ID별 등록된 사용자 정보 선택
2. 등록된 모든 사용자에 대한 정보 선택
3. 등록 중 사용자가 지정한 모든 데이터에 대한 정보 선택:
   • 성명;
   • 담당자 이메일 주소;
   • 연락 전화번호
   • 지정된 배송 주소: 우편번호, 지역명, 거리명, 집 번호, 건물 번호, 아파트 번호, 층수

메모!등록 시 사용자는 위 필드를 모두 작성하지 않을 수도 있습니다.

API 개발 계획

가까운 시일 내에 매장과 타사 애플리케이션 및 서비스의 상호 작용을 지원하는 인터페이스를 공개할 계획입니다.

1. 카탈로그 섹션.
2. 상품.
3. 바구니.
4. 할인이 있습니다.
5. 배송 방법.
6. 결제 방법.

beseller 플랫폼 API와의 상호 작용을 테스트하기 위해 테스트 스토어 beseller-api.shop.by가 생성되었습니다.

테스트 스토어에 액세스하려면 로그인 정보와 비밀번호를 제공해야 합니다. 개인 관리자에게 요청하시면 받으실 수 있습니다.

API와의 상호 작용을 테스트하기 전에 다음을 수행하는 것이 좋습니다.

1. 직접 여러 가지 주문을 하세요.
2. 뉴스레터를 구독하세요.
3. 주문한 항목과 가입자에 대한 정보가 매장 관리 패널에 어떻게 표시되는지 확인하세요.

매장 제어판은 beseller-api.shop.by/manager/에서 이용 가능합니다. 제어판 진입 시 로그인 및 비밀번호는 매장 접속 시 로그인 및 비밀번호와 유사합니다.

API를 통해 매장에 어떻게 연결하나요?

애플리케이션을 스토어와 연결하려면 다음 형식의 API 액세스 URL을 지정해야 합니다.

http://your_site_address:8082/graphql?token=your_personal_secret_key

비밀키는 개인 관리자에게 요청하시면 받으실 수 있습니다.

베셀러 플랫폼 API 작업을 위한 GraphQL 함수 및 변수

PHP 프로그래밍 언어를 사용하여 API에 연결하는 방법

베셀러 플랫폼 API 작업의 편의를 위해 다음을 사용할 수 있습니다.

1. PHP용으로 우리가 개발한 클래스입니다.
   1. Graphql클라이언트- 데이터를 서버로 수신하고 전송합니다.
   2. GraphQlHelper- 구현된 쿼리 및 돌연변이 API를 포함합니다.
2. 온라인 상점 데이터베이스에서 선택 및 변경을 수행하기 위해 클래스를 사용하는 예입니다.

로컬 환경 설정

API에 대한 요청 전송과 수신된 응답을 명확하게 보여주기 위해 로컬 환경을 사용할 수 있습니다.

GraphiQL Feen은 로컬 환경으로 사용되며, API에 대한 요청을 생성할 수 있는 Google Chrome 브라우저용 확장 프로그램입니다.

애플리케이션을 설치하면 브라우저의 주소 표시줄 근처에 애플리케이션 아이콘이 나타납니다.

GraphiQL Feen 애플리케이션을 열고 “SERVERS” 탭으로 이동하여 POST 전송 방법을 선택한 다음 API 액세스 URL을 지정합니다.

다음 주소를 테스트 URL로 사용해야 합니다.

로컬 환경이 구성되면 API에 대한 요청을 생성할 수 있습니다. 이렇게 하려면 '쿼리' 탭을 열어야 합니다.

GraphiQL Feen을 사용하여 beseller API에 대한 요청 구성 및 수신된 응답

스크린샷에 대한 설명:

1. 저장된 쿼리
2. 요청 입력 필드
3. 변수 입력 필드
4. 응답을 받았습니다
5. 시작 버튼

특정 기간 동안 접수된 주문 목록을 가져오기 위한 요청의 예

쿼리($first:Int, $offset:Int, $filter: OrdersFilterType)(
주문(첫 번째:$first, 오프셋:$offset, 필터:$filter)(
논평
상태(
ID
설명
이름
}
생성_날짜
업데이트 날짜
총 (
접미사
값
}
지불 (
이름
설명
비용(
접미사
값
}
}
배달(
이름
설명
비용(
접미사
값
}
}
통화(
은행 코드
강의
접미사
}
사용자 데이터(
이름
설명
값
}
}
}

접수된 주문에 대한 데이터를 검색하는 기간 지정

{
"필터": (
"date_after": "2017-11-16T00:00:01Z",
"date_before": "2017-11-23T00:00:01Z"
}
}

API의 응답 예시

{{
"데이터": (
"주문": [
{
"comment": "공식적인 내용입니다.",
"create_date": "2017-11-22 16:23:28",
"통화": [
{
"은행_코드": "BYN",
"코스": 10000,
"접미사": "문지르세요."
}
],
"배달": (
"비용": [
{
"suffix": "문지르세요.",
"값": 0
}
],
"description": "택배사",
"이름": "사용자 정의"
},
"지불": (
"비용": [
{
"suffix": "문지르세요.",
"값": 0
}
],
"description": "플라스틱 카드",
"이름": "사용자 정의"
},
"상태": (
"설명": "새 항목",
"ID": 1,
"이름": "새"
},
"총": [
{
"suffix": "문지르세요.",
"값": 4450
}
],
"update_date": "2017-11-22 16:23:28",
"사용자 데이터": [
{
"description": "이메일 주소",
"이름": "이메일",
"값": " [이메일 보호됨]"
},
{
"설명": "전화",
"이름": "전화",
"값": "784.392.3949 x69329"
},
{
"description": "주소",
"이름": "등록",
"value": "607 Erik Station Suite 057\nReynaberg, WY 83542-0037"
},
{
"description": "댓글",
"이름": "댓글",
"value": "Id nam illo optio."
},
{
"설명": "이름",
"이름": "피오",
"value": "조르디 만 MD"
}
]
}

조만간 모든 프로그래머는 다음과 같은 개념에 직면하게됩니다. API. 그러나 그러한 회의가 열리면 그것이 무엇인지, 왜 필요한지, 어떻게 사용하는지 모든 사람이 아는 것은 아닙니다. 그리고 이 기사에서 나는 여러분 중 일부의 지식 격차를 메우고 나의 실천 사례를 제시할 것입니다.

API (응용 프로그래밍 인터페이스) - 이것 응용 프로그래밍 인터페이스. 간단히 말해서 이는 다른 프로그램에서 사용할 수 있는 다양한 함수, 상수, 클래스 및 쿼리 형식의 집합입니다.

그것은 다음과 같이 간주될 수 있다 API- 이것은 우리가 구현을 모르는 특정 개체이지만 사용할 수 있습니다. 예를 들어, 컴퓨터는 구현을 아는 사람이 거의 없는 개체이지만 거의 모든 사람이 컴퓨터를 사용하여 비디오 보기, 인터넷 서핑, 텍스트 인쇄 등의 작업을 수행할 수 있습니다. 이 모든 것이 어떻게 작동하는지 아는 사람은 거의 없지만 거의 모든 사람이 할 수 있습니다.

예 API~이다 윈도우 API, 오픈GL API, 다이렉트3D API등등.

예를 들면 얼마전에 나도 직접적으로 접한 적이 있다. API. 메일링 리스트 서비스에 등록했습니다." SmartResponder.ru" 그리고 사람들이 구독하기 시작한 뉴스레터를 시작했습니다. 작업은 다음과 같습니다. 구독 후 24시간 이내에 내 유료 비디오 강좌를 할인된 가격으로 구매할 수 있습니다. 구독자에 대한 모든 정보가 서버에 저장되기 때문에 " SmartResponder.ru"를 선택한 다음 일반 액세스(예: DB) 이 데이터에 접근할 수는 없었지만 이를 구현하는 데 필요했습니다. 고맙게도 " SmartResponder.ru"너만의 것을 가져라 API, 내가 사용한 것입니다.

나는 그들에게서 발견했다 API결과적으로 구독 날짜를 가져오는 요청 형식입니다. 더 나아가 곱슬 곱슬하다해당 요청을 보냈고 특정 구독에 필요한 구독 날짜를 받았습니다. 이메일 주소. 다음은 표준 처리 및 결과 출력이다.

거의 모든 운영 체제(UNIX, Windows, Mac OS 등)에는 프로그래머가 해당 운영 체제용 애플리케이션을 만들 수 있는 API가 있습니다. 운영 체제의 주요 API는 시스템 호출 집합입니다.

정의 3: 시스템 호출- 응용 프로그램이 운영 체제 커널에 액세스하여 작업을 수행합니다.

최신 운영 체제는 실행 중인 컴퓨팅 프로세스(멀티태스킹)와 권한 분리 사이의 시간 분할을 제공하여 실행 프로그램이 다른 프로그램 및 하드웨어의 데이터에 액세스하는 것을 방지합니다. OS 커널은 권한 있는 프로세서 모드에서 실행됩니다. 프로세스 간 작업이나 하드웨어에 대한 액세스가 필요한 작업을 수행하기 위해 프로그램은 호출 프로세스의 권한에 따라 이러한 호출의 실행을 실행하거나 거부하는 커널을 호출합니다.

프로그래머의 관점에서 볼 때 시스템 호출은 일반적으로 시스템 라이브러리의 서브루틴이나 함수에 대한 호출처럼 보입니다. 그러나 그러한 함수나 서브루틴에 대한 호출의 특별한 경우인 시스템 호출은 시스템 라이브러리에 대한 보다 일반적인 호출과 구별되어야 합니다. 왜냐하면 후자는 권한 있는 작업의 실행을 요구하지 않을 수 있기 때문입니다.

소프트웨어 산업에서 표준 기능을 위한 공통 표준 API는 공통 API를 사용하는 모든 프로그램이 동등하게 또는 적어도 일반적으로 익숙한 방식으로 작동하도록 보장하기 때문에 중요합니다. GUI API의 경우 이는 프로그램이 유사한 사용자 인터페이스를 갖게 되어 새로운 소프트웨어 제품을 더 쉽게 배울 수 있음을 의미합니다.

반면, 다양한 운영 체제의 API 차이로 인해 플랫폼 간에 애플리케이션을 포팅하는 것이 매우 어렵습니다. 이러한 복잡성을 해결하는 다양한 방법이 있습니다. "중간" API(WxWidgets, Qt, GTK 등의 GUI API) 작성, 한 OS의 시스템 호출을 다른 OS의 시스템 호출로 매핑하는 라이브러리 작성(Wine, cygwin 등), 프로그래밍 언어(예: C 표준 라이브러리)에 코딩 표준 도입, 다양한 플랫폼에서 구현되는 해석 언어 작성(sh, python, perl, php, tcl, Java 등) .

또한 프로그래머는 동일한 결과를 얻기 위해 여러 가지 다른 API를 사용할 수 있는 경우가 많습니다. 또한 각 API는 일반적으로 낮은 추상화 수준의 API 소프트웨어 구성 요소를 사용하여 구현됩니다.

예를 들어, 브라우저에서 "Hello, world!"라는 줄을 보려면 최소한의 제목과 이 줄을 포함하는 간단한 본문이 있는 HTML 문서를 생성하면 됩니다. 브라우저가 이 문서를 열면 브라우저 프로그램은 HTML 문서를 처리하는 라이브러리에 파일 이름(또는 이미 열려 있는 파일 설명자)을 전달합니다. 그러면 운영 체제 API를 사용하여 이 파일을 읽고 그 구조를 이해합니다. 그런 다음 "창 지우기", "선택한 글꼴로 "Hello, world!" 쓰기"와 같은 작업을 위해 표준 그래픽 기본 요소의 API 라이브러리를 순차적으로 호출합니다. 이러한 작업을 수행하는 동안 그래픽 기본 요소 라이브러리는 적절한 요청으로 창 인터페이스 라이브러리에 연결하고 이 라이브러리는 운영 체제 API에 연결하여 비디오 카드 버퍼에 데이터를 씁니다.

게다가 거의 각 수준에는 실제로 몇 가지 가능한 대체 API가 있습니다. 예를 들어 HTML이 아닌 LaTeX로 소스 문서를 작성할 수 있으며 표시를 위해 모든 브라우저를 사용할 수 있습니다. 다른 브라우저는 일반적으로 다른 HTML 라이브러리를 사용하며, 더 나아가 (일반적으로 말하면) 다른 기본 라이브러리와 다른 운영 체제를 사용하여 전체 내용을 컴파일할 수 있습니다.

따라서 기존 다중 레벨 API 시스템의 주요 과제는 다음과 같습니다.

· 한 API 시스템에서 다른 API 시스템으로 프로그램 코드를 이식하는 데 어려움이 있습니다(예: OS 변경 시).

·낮은 수준에서 높은 수준으로 이동할 때 기능이 손실됩니다. 대략적으로 말하면, 각 API "계층"은 일부 표준 작업 세트의 실행을 용이하게 하기 위해 생성됩니다. 그러나 동시에 낮은 수준의 API에서 제공하는 다른 작업을 수행하는 것이 정말 어려워지거나 근본적으로 불가능해집니다.

메모. 포팅- 프로그래밍에서 이식이란 프로그램이나 그 일부를 원래 작성된 환경과 다른 환경에서 작동하면서 사용자 속성을 최대한 보존하도록 프로그램이나 그 일부를 적용하는 것을 의미합니다.

이 단기적인 용어는 개발 경험이 어느 정도 있는 모든 사람에게 잘 알려져 있습니다. 그러나 모든 사람이 그것이 정확히 무엇을 의미하고 왜 필요한지 이해하는 것은 아닙니다. 개발자 피터 가자로프그의 블로그에서 API에 대해 간단한 단어로 이야기했습니다.

약어 API는 "애플리케이션 프로그래밍 인터페이스"(애플리케이션 프로그래밍 인터페이스, 애플리케이션 프로그래밍 인터페이스)를 나타냅니다. 대부분의 대기업은 어떤 단계에서는 클라이언트용 또는 내부용 API를 개발합니다. API가 개발 및 비즈니스에 어떻게 사용되는지 이해하려면 먼저 World Wide Web의 작동 방식을 이해해야 합니다.

World Wide Web 및 원격 서버

WWW는 모든 페이지가 저장되어 있는 상호 연결된 서버의 거대한 네트워크로 생각할 수 있습니다. 일반 노트북은 네트워크의 전체 웹사이트를 서비스할 수 있는 서버로 바뀔 수 있으며, 개발자는 로컬 서버를 사용하여 웹사이트를 광범위한 사용자에게 공개하기 전에 생성합니다.

브라우저 주소창에 입력하면 www.facebook.com해당 요청이 원격 Facebook 서버로 전송됩니다. 브라우저가 응답을 받으면 코드를 해석하고 페이지를 표시합니다.

사용자가 인터넷 페이지를 방문할 때마다 원격 서버의 API와 상호 작용합니다. API는 요청을 받고 응답을 보내는 서버의 구성 요소 부분입니다.

클라이언트에게 서비스를 제공하는 방법으로서의 API

많은 회사에서 API를 기성 제품으로 제공합니다. 예를 들어 Weather Underground는 날씨 데이터 API에 대한 액세스를 판매합니다.

사용 시나리오:소규모 회사의 웹사이트에는 고객을 위한 예약 양식이 있습니다. 회사는 Google Calendar를 여기에 통합하여 고객이 자동으로 이벤트를 만들고 다가오는 회의에 대한 세부정보를 입력할 수 있는 기능을 제공하려고 합니다.

API 애플리케이션:목표는 사이트 서버가 지정된 세부정보로 이벤트를 생성하라는 요청으로 Google 서버에 직접 접속하고, Google의 응답을 받아 처리하고, 적절한 정보(예: 사용자에게 확인 메시지)를 브라우저에 보내는 것입니다. .

또는 회사의 서버를 거치지 않고 브라우저가 Google의 서버 API에 요청할 수도 있습니다.

Google Calendar API는 네트워크에 있는 다른 원격 서버의 API와 어떻게 다릅니까?

기술적으로 차이점은 요청과 응답의 형식에 있습니다. 전체 웹페이지를 생성하기 위해 브라우저는 HTML 마크업 언어로 된 응답을 기대하는 반면, Google Calendar API는 단순히 JSON과 같은 형식으로 데이터를 반환합니다.

API에 대한 요청이 회사 웹사이트의 서버에 의해 이루어진 경우 이는 클라이언트입니다(사용자가 웹사이트를 열 때 브라우저가 클라이언트인 것처럼).

API 덕분에 사용자는 회사 웹사이트를 떠나지 않고도 작업을 수행할 수 있는 기회를 얻습니다.

대부분의 최신 웹사이트는 최소한 몇 가지 타사 API를 사용합니다. 많은 작업에는 라이브러리나 서비스 등 이미 타사 개발자가 제공하는 기성 솔루션이 있습니다. 기성 솔루션을 사용하는 것이 더 쉽고 안정적인 경우가 많습니다.

많은 개발자가 API를 사용하여 서로 상호 작용하는 여러 서버에 애플리케이션을 배포합니다. 기본 애플리케이션 서버에 대한 지원 기능을 수행하는 서버를 마이크로서비스라고 합니다.

따라서 회사가 사용자에게 API를 제공한다는 것은 단순히 데이터만 응답으로 반환하는 일련의 특수 URL을 생성했다는 의미입니다.

이러한 요청은 종종 브라우저를 통해 전송될 수 있습니다. HTTP 데이터 전송은 텍스트 형식으로 발생하므로 브라우저는 항상 응답을 표시할 수 있습니다. 예를 들어, 브라우저를 통해 액세스 토큰 없이 GitHub API(https://api.github.com/users/petrgazarov)에 직접 액세스하고 JSON 형식으로 다음 응답을 받을 수 있습니다.

브라우저는 코드에 삽입할 수 있는 JSON 응답을 완벽하게 표시합니다. 그러한 텍스트에서 데이터를 추출하여 귀하의 재량에 따라 사용하는 것은 쉽습니다.

추가 API 예제

"응용 프로그램"이라는 단어는 다른 의미를 가질 수 있습니다. API의 맥락에서 이는 다음을 의미합니다.

• 특정 기능을 가진 소프트웨어,
• 전체 서버, 전체 애플리케이션 또는 애플리케이션의 별도 부분.

환경과 명확하게 구별될 수 있는 모든 소프트웨어는 영어 약어의 "A"를 대체할 수 있으며 일종의 API를 가질 수도 있습니다. 예를 들어 개발자가 타사 라이브러리를 코드에 구현하면 이는 전체 애플리케이션의 일부가 됩니다. 독립형 소프트웨어인 라이브러리에는 나머지 애플리케이션 코드와 상호 작용할 수 있는 일종의 API가 있습니다.

객체지향 디자인에서 코드는 객체의 컬렉션으로 표현됩니다. 애플리케이션에는 수백 개의 개체가 서로 상호 작용할 수 있습니다. 각각에는 자체 API 세트가 있습니다. 공공의애플리케이션의 다른 개체와 상호 작용하기 위한 속성 및 메서드입니다. 객체에는 다음이 있을 수도 있습니다. 사적인, 환경에서 숨겨져 있으며 API가 아닌 내부 논리입니다.

또한 프로그래머는 동일한 결과를 얻기 위해 여러 가지 다른 API를 사용할 수 있는 경우가 많습니다. 또한 각 API는 일반적으로 낮은 추상화 수준의 API 소프트웨어 구성 요소를 사용하여 구현됩니다.

예를 들어 브라우저에서 "Hello, world!"라는 줄을 보려면 당신이 해야 할 일은 최소한의 제목과 이 줄을 포함하는 간단한 본문으로 HTML 문서를 만드는 것뿐입니다. 브라우저가 이 문서를 열면 어떻게 되나요? 브라우저 프로그램은 HTML 문서를 처리하는 라이브러리에 파일 이름(또는 이미 열려 있는 파일 설명자)을 전달합니다. 그러면 운영 체제 API를 사용하여 이 파일을 읽고 구조를 이해하여 "clear the file"과 같은 작업을 호출합니다. window”, “write Hello, world in the selected 글꼴!”, 이러한 작업 중에 그래픽 프리미티브 라이브러리는 해당 요청으로 창 인터페이스 라이브러리에 연결하고 이 라이브러리는 “put it in”과 같은 요청으로 운영 체제 API에 연결합니다. 내 비디오 카드가 이것을 버퍼링합니다."

게다가 거의 각 수준에는 실제로 몇 가지 가능한 대체 API가 있습니다. 예를 들어 소스 문서를 HTML이 아닌 LaTeX로 작성할 수 있으며 표시를 위해 모든 브라우저를 사용할 수 있습니다. 다른 브라우저는 일반적으로 다른 HTML 라이브러리를 사용하며, 더 나아가 (일반적으로 말하면) 다른 기본 라이브러리와 다른 운영 체제를 사용하여 전체 내용을 컴파일할 수 있습니다.

따라서 기존 다중 레벨 API 시스템의 주요 과제는 다음과 같습니다.

• 한 API 시스템에서 다른 API 시스템으로 프로그램 코드를 이식하는 데 어려움이 있습니다(예: OS 변경 시).
• 낮은 수준에서 높은 수준으로 이동할 때 기능이 손실됩니다. 대략적으로 말하면, 각 API "계층"은 일부 표준 작업 세트의 실행을 용이하게 하기 위해 생성됩니다. 그러나 동시에 낮은 수준의 API에서 제공하는 다른 작업을 수행하는 것이 정말 어려워지거나 근본적으로 불가능해집니다.

기본 API 유형

• API 액세스는 내부 개발자에게만 제한됩니다.
• 애플리케이션은 기업 직원을 대상으로 합니다.

비즈니스 동인:

• 개발 일관성
• 비용 절감
• 개발 효율성 향상

파트너 API

• API는 제한된 비즈니스 파트너에게만 제공됩니다.
• 애플리케이션은 최종 소비자 및 비즈니스 사용자를 대상으로 합니다.

비즈니스 동인:

• 개발 프로세스 자동화
• 파트너십 개발
• 파트너와의 상호 작용 프로세스 최적화

공개 API

모든 외부 개발자에게 액세스 권한이 부여됩니다. 애플리케이션은 최종 사용자를 대상으로 합니다.

비즈니스 동인:

• 새로운 서비스 개발
• 생태계 개발
• 옴니채널 상호작용

가장 유명한 API

운영 체제 API

GUI API

• Direct3D(DirectX의 일부)
• DirectDraw(DirectX의 일부)

오디오 API

• DirectSound(DirectX의 일부)
• DirectMusic(DirectX의 일부)

인증 시스템 API

API 경제의 원리와 사용

• API 작업에는 측정 가능한 가치가 있어야 합니다. 어떤 개발자도 사용하지 않을 API를 생성하는 데 리소스를 낭비하지 마세요.
• 특정 사용자가 있는 경우에만 API를 생성하세요. 이를 필요로 하는 파트너나 생태계가 있어야 합니다.
• 일반 기업은 항상 자체적으로 생성하는 것보다 더 많은 API를 사용합니다. 그의 부서에서는 많은 API를 처리하고 CIO는 이를 관리하는 임무를 맡게 됩니다.
• API는 사물 인터넷, 소비자 기능, 분석 및 정보 시스템에 매우 중요합니다. API를 만들 때 이러한 사항을 잊어버렸다면 신중하게 생각하세요.

API를 통해 조직은 개인화된 사용자 경험을 만들 수 있습니다.

고객의 기대와 행동이 변화하고 있습니다

구매자:

• 각자의 조건에 맞는 개별화된 접근 방식 필요
• 종합적인 통합 서비스를 기대하세요
• 그들은 자신의 요구 사항을 더 잘 충족하는 사람으로 전환할 것입니다.

조직:

• 대화형 웹사이트, 이러한 목적을 위해 만들어진 모바일 애플리케이션 및 기타 친숙한 디지털 인터페이스를 통해 고객과 상호작용합니다.
• 종합적인 통합 서비스를 기대하세요
• 그들은 자신의 요구 사항을 더 잘 충족하는 사람에게로 넘어갈 것입니다.

API는 어디에나 있습니다!

사건의 연대기

2019

Skolkovo가 참여한 PJSC VTB Bank와 공동으로 TAdviser가 실시한 연구: 러시아 은행 부문에서 API 혁신이 시작되었습니다.

중앙은행은 오픈 API 분야 시범사업에 참여하기 위해 약 20개 은행을 초청했다.

2019년 8월 21일, 러시아 은행이 유라시아 경제 연합(EAEU) 내에서 은행 서비스 통합을 위한 개방형 API(응용 프로그램 인터페이스) 분야의 파일럿 프로젝트의 코디네이터 역할을 한 것으로 알려졌습니다. 자료가 출판되는 시점에 중앙은행은 EAEU 국가의 중앙은행과 함께 시범 시행을 준비하기 위해 노력하고 있습니다. 중앙은행의 제안을 받은 은행가들은 이 사실을 Kommersant에게 전했다. 전체적으로 약 20개의 신용 기관이 규제 기관의 서신을 받았으며, 8월 23일까지 참여할 준비가 되었는지 응답해야 합니다. 자세히 읽어보세요.

증권업계는 API를 받아들일 준비가 되어있습니다

2019년 8월 2일, SWIFT와 BCG의 공동 연구에서 효율성을 높이고 서비스를 제공하려는 기업의 욕구를 배경으로 API 사용이 증가하는 것으로 밝혀졌습니다.

기업들이 더 큰 효율성과 현대적인 비즈니스 모델을 추구함에 따라 증권 업계는 애플리케이션 프로그래밍 인터페이스(API) 채택의 전환점에 가까워지고 있습니다.

BCG 조사에 따르면 자산 관리자의 API 인식은 2018년 한 해에만 26%(46%에서 72%) 증가했습니다. 상업적인 관심이 높아지면서 특히 자산 관리 회사와 보관 기관 간의 파일럿 계획과 사용 사례가 늘어나고 있습니다.

API는 증권 업계가 다양하고 다양한 자산 유형, 복잡한 정보 교환, 증가하는 수수료 압력에 대처하는 데 도움이 될 수 있는 잠재력을 가지고 있습니다. 보고서는 API가 전체 산업에 도움이 될 수 있는 네 가지 영역을 식별합니다.

• 자동화된 데이터 교환을 통한 효율성 및 비용 절감
• 정산현황, 일중리스크 등 실시간 정보에 접근
• 추가 서비스: 풍부한 데이터 및 분석
• 서비스 제공업체가 시장 참가자 간의 성과를 비교할 수 있는 운영 지표

규제 프레임워크가 부족하고 API를 채택하려는 시장 참여자의 의지가 일관성이 부족하기 때문에 다른 금융 서비스 산업에 비해 증권 산업에서 API 채택이 더디게 진행되었습니다. 자산 관리 회사는 기술적 정교함과 API를 통한 제공업체와의 상호 작용에 대한 개방성이 크게 다릅니다. BCG 설문 조사 응답자의 약 56%는 거래 후 API 채택 수준을 "실험적"이라고 생각하는 반면, 21%만이 "높음" 또는 "중간"이라고 답했습니다.

API는 결제 산업 및 기타 은행 분야에서 그랬던 것처럼 사후 거래 혁신의 강력한 원동력이 될 수 있습니다. 이 기술에 대한 관심이 높아지고 있으며 첫 번째 실험 결과는 유망해 보입니다. 그러나 실제로 API의 광범위한 채택을 촉진하고 가속화하려면 표준에 대한 불확실성을 제거하고 기술 성숙도에 대한 이해를 높여야 합니다. SWIFT의 증권 및 외환 시장 부서 책임자인 Juliet Kennel은 이렇게 말했습니다.

보고서는 업계가 API를 구현해야 하는 네 가지 이유를 제시합니다.

• 공통 인프라 내 상호 작용. ID, 인증, 보안, 네트워크 관리 등 API 솔루션의 기본 요소는 개별 기업 간이 아닌 업계 수준에서 합의해야 합니다.
• 상호 운용성을 유지하기 위해 API 표준 조정. 여러 표준이 확산되면 API 사용의 효율성이 떨어질 수 있습니다. 업계에는 모든 제공업체에서 작동하는 단일 API 표준이 필요합니다.
• p2p 솔루션이 아닌 네트워크 API 지원. 기업은 네트워크 API의 이점을 누릴 수 있습니다. 예를 들어 브로커-딜러의 정산 상태를 확인하기 위한 단일 호출을 여러 관리인에게 동시에 보낼 수 있습니다. 네트워크 솔루션은 데이터 설명과 기타 API 특성 모두에 대한 융합을 지원합니다.
• 엄격한 안전 및 지속 가능성 표준을 충족합니다.성공적인 개발을 위해서는 모든 API 솔루션이 높은 수준의 데이터 보호 및 지속 가능성을 갖춰야 합니다.

API는 전체 은행 부문의 디지털 혁신에서 핵심 기술 중 하나가 되었습니다. API는 이제 증권 산업에 진출하고 있으며 디지털 서비스로 전환하려는 기업들 사이에서 선도적인 기술이 되고 있습니다. 상호 운용성과 보안 측면에서 API 채택에 대한 기존의 어려움에도 불구하고 우리는 이러한 어려움이 극복될 것이라고 믿으며 가까운 시일 내에 기술이 추가로 구현될 것으로 기대합니다. BCG의 증권 서비스 책임자인 Sumitra Karthikeyan은 이렇게 말했습니다.

SWIFT를 기반으로 증권 시장에 API를 도입하면 시장 참여자, 특히 관리 회사와 최종 투자자를 위한 비용 절감 및 추가 비즈니스 기회 창출과 같은 주요 목표 달성을 보장할 수 있습니다. 이에 NSD는 개방형 API 활용을 연구하고 있으며, API 기술 표준화 및 글로벌 포스트트레이딩 분야에서 이 기술의 실용화 문제에 대해 SWIFT와 적극적으로 협력하고 있으며,오픈뱅킹 플랫폼 Tink는 다음과 같이 주장합니다.