시대의 발전과 함께 API는 현대 기업이 온라인 비즈니스를 개발하고 데이터 운영을 표준화하는 주요 방법이 되었습니다. 협력과 교류를 거듭하며 점차 API 경제활동으로 발전해 나갔습니다. API 서비스는 개발자와 수요자의 상호 협력의 산물입니다. API 서비스는 주로 개발자가 특정 플랫폼이나 리소스를 사용하여 수요자에게 API 인터페이스를 제공하는 것을 말합니다. 이는 특정 개발 플랫폼일 수도 있고 데이터 정보, 표준화된 데이터베이스, 리소스 라이브러리 등과 같은 리소스일 수도 있습니다. API 서비스는 고품질의 정량화 가능한 거래를 달성하기 위해 다양한 기관 간의 우수한 데이터 상호 작용 서비스를 제공합니다.
현재까지 전 세계적으로 2천만 명이 넘는 API 개발자가 100억 개가 넘는 API를 만들었습니다. 인터넷이 있는 곳에는 API가 있습니다. API는 미래를 여는 열쇠가 되었다고 할 수 있습니다. API는 모든 데이터 상호 작용의 관문이자 개발자가 데이터와 서비스를 출력하는 중요한 방법입니다.
1. API 1.0 시대, 기업 내부 시스템 통합에 초점
1989년으로 거슬러 올라가면 Tim Berners-Lee는 웹 1.0의 출현을 정의했습니다. Web 1.0은 사용자가 웹 페이지를 볼 수 있는 간단한 정적 페이지만 제공했습니다. 최초의 브라우저인 모자이크의 출현은 인터넷의 선례를 만들었습니다. 당시에는 API 서비스가 아직 형성되지 않았습니다. 기업 내부 관리 시스템 기술이 성숙 단계에 도달한 2000년까지 기업에서는 기업 커뮤니케이션을 자동화하기 위해 RESTful API를 도입하기 시작했고 , 공개 API, 비공개 API, 내부 API를 설계하고 제작했습니다. 그 중 공개 API는 클라이언트 개발을 기반으로 하는 소비자 중심 애플리케이션이며, 비공개 API는 재구성 및 현대화가 가능한 기업 내부 작업 관리를 위한 효율적인 통신이며, 내부 API는 분석 결과의 정확성을 최적화하기 위한 것입니다. 프라이빗 API 운용 과정에서 생성되는 다양한 데이터를 암호화해 보호하는 것이 지능화의 핵심이다.
인터넷에 대한 사람들의 요구 사항이 날로 증가함에 따라 웹 2.0의 등장으로 지도 의 인기 와 디자인 가능한 외관으로 인해 사람들은 웹 도구를 사용하여 자유롭게 작업할 수 있게 되었습니다. 2003년부터 2006년까지 소셜 플랫폼이 등장하면서 셀프미디어 산업이 부흥하기 시작했고, API 서비스는 다시 한번 기술 혁명을 일으켰고, 사람들은 웹 링크, 사진 등 다양한 콘텐츠에 API 서비스를 사용하기 시작했습니다. 2006년부터 2008년까지 API 1.0은 빠른 발전 추세를 보였습니다.
이 과정에서 API 1.0 서비스의 특징을 요약할 수 있다. 초기 API 서비스는 주로 서버와 브라우저 간의 단명한 링크를 통해 단일 아키텍처 형태로 존재했기 때문에 정보 수집, 저장, 보호에 이르기까지 명확한 계층 구조를 갖고 있었으며 명확한 비즈니스 로직 파이프라인이 있었습니다. IT 아키텍처. 구조가 명확하고 명확하며, 기업 데이터의 안전한 유통을 보장하기 위한 데이터 보호에 대한 사전 인식이 있다는 것이 장점입니다. 단점은 업계 내 기업 간 데이터 통신 요구를 충족할 수 없다는 점입니다. 정보를 호출할 때 전체 아키텍처를 복사해야 하는 경우가 많아 호출이 반복되고 속도가 느리며 정보가 번거롭고 복잡해지기 쉽습니다. 사회적, 경제적 이익과 서비스 프로세스에 영향을 미칩니다.
2. API 2.0 시대, 크로스 플랫폼 시스템 도킹 실현
2008년부터 웹 2.0 시대의 흐름에 따라 기업의 시스템 자원은 마침내 내부 범위를 넘어섰고, UDDI 기술의 등장으로 새로운 API 포트가 탄생하게 되었습니다. UDDI는 주로 데이터 정보를 기술하고 발견하고 통합하는 검색 프레임워크로 총칭할 수 있습니다 . 사용자는 인터넷을 사용하여 서비스를 설명하고 관련 정보를 검색할 수 있습니다. UDDI는 내부 기업뿐만 아니라 더 많은 기업 사용자를 대상으로 하기 때문에 서비스 아키텍처라고 할 수 있습니다. 관련 UDDI API 포트는 SOAP 액세스 프로토콜을 기반으로 데이터를 직접 검색 할 수 있습니다. SOAP는 검색 컴퓨팅 환경에서 정보 교환에 사용되므로 개발자는 플랫폼 독립적인 방식으로 개체, 서버 등에 액세스할 수 있습니다.
API 2.0 시대 API 서비스의 특징을 토대로 SOA 아키텍처 설계 라 할 수 있다 . SOA의 장점은 단일 계층 아키텍처의 단점을 없애고 계층형 아키텍처를 채택하여 어느 정도 정보의 중복을 피할 수 있다는 점입니다. 동시에 메시지 버스의 개념을 더 제안합니다. MQ) 및 서비스 재사용. 이 모델에서 IT 아키텍처는 기능적 특성에 따라 구성 요소 계층, 웹 서비스 계층 및 비즈니스 프로세스 계층이라는 세 가지 주요 계층으로 구분됩니다. 그 중 구성 요소 계층에는 주로 다양한 유형의 응용 시스템이 포함됩니다. 중요한 IT 설계 프로세스에서 구성 요소 계층은 분산된 기술적 특성을 지닌 독립적인 정보 구성 요소를 형성하며 이는 응용 프로그램의 통합 개발에 일정한 이점을 제공합니다. 웹 서비스 계층은 통합 문제를 해결하기 위해 존재합니다. 웹 서비스 계층은 설명 언어를 사용하여 개별 비즈니스 기능을 정의하고 분산 구성 요소 기술을 해당 문서 정보( WSDL) 로 변환하는 것을 지원합니다 . 개발자는 비즈니스 운영을 수행하기 위해 WSDL의 관련 설명을 따르기만 하면 됩니다. 비즈니스 프로세스 계층은 최종 비즈니스의 실제 운영 및 구현이며 비즈니스는 웹 서비스 계층을 기반으로 구축됩니다.
그러나 단점도 분명합니다. 이 아키텍처는 체계적인 전체 배포와 분리되지 않습니다. 개발자가 부품을 업데이트하고 유지 관리하려는 경우 전체 아키텍처 조정이 수반되어 운영, 유지 관리 및 업그레이드가 어렵고 실제 운영 조건을 따르지 않는 경우가 많습니다. . 사람들은 보다 유연하고 민첩한 아키텍처 모델을 요구하기 시작했습니다.
3. API 3.0 시대, 클라우드 플랫폼 분산 애플리케이션 아키텍처
2014년에는 '클라우드 컴퓨팅' 개념이 전 세계로 확산되었습니다. 인터넷 산업의 생태적 변화는 많은 제조업체의 개념을 변화시켰으며 전통적인 독립 애플리케이션 아키텍처는 점차 폐기되었습니다. 업계는 수직적 발전 추세를 보이고 있으며 사업 형태가 단순한 컴퓨터 PC 네트워크에서 WAP 단말기, 모바일 단말기, 전용 단말기 등으로 변화하고 있으며, API 서비스에도 새로운 변화가 나타나 클라우드 플랫폼 분산 애플리케이션 개념이 등장하고 있습니다.
클라우드 플랫폼 분산 애플리케이션은 주로 Rest 아키텍처를 사용하여 여러 프로세스가 동시에 실행되고 오류가 발생할 때 애플리케이션을 분할하는 방법에 대한 문제를 속도와 효율성 모두에서 해결합니다. Rest 작업의 기본 로직은 웹 아키텍처를 기반으로 문제 위치를 파악하고 다양한 솔루션을 비교하는 것입니다. Rest 아키텍처는 클라우드 컴퓨팅에서 널리 사용되며 실행 중인 문제를 빠르게 식별하고 솔루션을 제공할 수 있습니다.
현대 기업의 경우 디지털 전환 이후 기존 중앙 집중식 스토리지의 규모가 병목 현상에 도달했습니다. 분산형 클라우드 인프라는 주요 시스템을 다양한 작업 노드로 분리하고 노드 및 스토리지 용량 간의 상호 협력 및 운영을 통해 효율적이고 빠른 컴퓨팅을 제공할 수 있습니다. . 스토리지 기능은 통합 배포와 분리 배포로 나눌 수 있습니다. 통합 배포는 여러 사용자에게 동시에 비즈니스 기능을 제공하고 배포 계획을 지능적으로 생성할 수 있는 클라우드 플랫폼 관리 영역 서비스에서 자주 사용됩니다. 이는 개발자가 프런트엔드와 백엔드에서 동시에 독립적인 네트워크 배포를 수행할 수 있음을 의미합니다. 이 아키텍처의 장점은 로컬 변경이 전체에 미치는 영향을 걱정하지 않고 유연하게 디버깅하고 호출할 수 있다는 점입니다. 단점은 데이터가 공용 네트워크에 노출되기 때문에 보안이 떨어진다는 것입니다.
"Qing Yu Nian 2"의 불법 복제된 리소스가 npm에 업로드되어 npmmirror가 unpkg 서비스를 중단하게 되었습니다. Zhou Hongyi: Google에 남은 시간이 많지 않습니다. time.sleep(6) 여기서는 어떤 역할을 합니까? 리누스는 '개사료 먹기'에 가장 적극적입니다! 새로운 iPad Pro는 12GB의 메모리 칩을 사용하지만 8GB의 메모리를 가지고 있다고 주장합니다. People's Daily Online은 사무용 소프트웨어의 마트료시카 스타일 충전을 검토합니다. "세트"를 적극적으로 해결해야만 Flutter 3.22 및 Dart 3.4 출시가 가능 합니다. 'ref/reactive'가 필요 없는 Vue3의 새로운 개발 패러다임, 'ref.value'가 필요 없음 MySQL 8.4 LTS 중국어 매뉴얼 출시: 데이터베이스 관리의 새로운 영역을 마스터하는 데 도움 Tongyi Qianwen GPT-4 수준 메인 모델 가격 인하 97% 증가, 1위안 200만 토큰