응용 프로그래밍 인터페이스. API란 무엇이며 왜 필요한가요? API 유형
API를 사용하여 작업하는 것은 보람이 있을 수도 있고 실망스러울 수도 있습니다. 한편으로는 다른 애플리케이션과 상호 작용함으로써 애플리케이션의 청중 도달 범위와 "와우" 효과를 크게 높일 수 있습니다. 반면에 여기에는 수많은 문서를 읽고, 인증 전략을 연구하고, 정보가 없는(또는 누락된) 오류 메시지를 구문 분석하는 작업이 포함됩니다.
우선 API(응용 프로그래밍 인터페이스)가 무엇인지 아직 완전히 이해하지 못했다면 Skillcrush의 설명을 읽고 이 기사의 첫 번째 부분을 읽어보세요.
"API"는 놀라울 정도로 광범위한 개념입니다. 애플리케이션이 다른 애플리케이션과 "대화"할 때마다 일종의 API를 통해 그렇게 합니다. Rails의 다른 부분과 같이 애플리케이션 내의 구성 요소도 API를 통해 서로 통신합니다. 이들은 각각 고유한 특정 작업을 수행하는 데 필요한 데이터를 제공하는 다소 독립적인 하위 애플리케이션입니다. 앱 세계에서는 모든 것이 API입니다!
보다 동적인 프런트엔드 기능을 갖춘 애플리케이션(단일 페이지 Javascript 애플리케이션과 개별 AJAX 호출이 포함된 간단한 애플리케이션 모두)을 구축하면 실제로는 한두 줄의 코드에 불과한 자체 API를 통해 Rails 백엔드와 통신합니다. , HTML 대신 JSON 또는 XML을 제공하는 방법을 컨트롤러에 알려줍니다.
이 튜토리얼에서는 자신만의 API를 만드는 방법을 배웁니다. 후속 강의에서는 다른 애플리케이션의 API와 상호 작용하는 방법을 다룹니다. 수업은 이 주제에 대해 배우기 위한 좋은 발판이 되어야 하지만 모든 사례를 완전히 다룰 수는 없습니다. API 작업의 가장 큰 부분은 문서를 읽고 API가 원하는 것이 무엇인지 파악하는 방법을 아는 것입니다.
고려해야 할 사항
질문을 검토하고 답을 알고 있는지 확인하세요. 작업을 완료한 후 다시 테스트해 보세요.
- HTTP 요청을 보낼 때 응답으로 예상되는 파일 유형을 Rails가 이해하는 방법입니다.
- #respond_to 메소드의 목적은 무엇입니까?
- 해당 개체에 포함하지 않으려는 속성을 지정하면서 User 개체를 어떻게 반환합니까(즉, User.first만 반환할 수는 없음)?
- #to_json 메서드의 이면에 있는 2단계를 지정하세요.
- 오류 메시지만 렌더링하도록 컨트롤러 작업에 어떻게 지시합니까?
- 자신만의 오류 메시지를 만드는 방법은 무엇입니까?
- API에 대한 프로그래밍 방식 연결을 허용하려는 경우 세션 기반 컨트롤러 인증 방법을 사용할 수 없는 이유는 무엇입니까?
- "서비스 지향 아키텍처"란 무엇입니까?
API 기본 사항
Rails 애플리케이션은 실제로 이미 API이지만, API라고 생각하지 않을 수도 있습니다. 사용자가 시작하는 웹 브라우저도 프로그램이므로 사용자가 새 페이지를 열 때 실제로 Rails 애플리케이션에 API 요청을 보냅니다. HTML 템플릿을 렌더링하는 것은 이 기능을 표준 응답 유형으로 서버 프로그램에 굽고 다른 모든 것을 특이한 것으로 간주하는 일반적인 작업이기 때문에 이렇게 생각하는 경향이 있습니다.
그러나 브라우저를 사용하는 데 따른 모든 어려움을 겪을 필요가 없는 요청을 하고 싶은 경우가 많습니다. 페이지 구조(HTML)에는 관심이 없지만 그 대가로 깨끗한 데이터를 원할 수 있습니다. 모든 사용자의 목록을 얻고 싶다고 가정해 보겠습니다. http://yourapplication.com/users 와 같은 것을 요청할 수 있습니다. 그러면 반드시 #index 작업이 실행되고 모든 앱 사용자 목록이 렌더링됩니다.
하지만 원하는 것이 사용자 목록뿐이라면 왜 이런 추가 정보를 일일이 입력해야 할까요? 가장 간단한 옵션은 동일한 URL로 요청을 보내고 그 대가로 JSON 또는 XML 응답을 기대하는 것입니다. Rails 컨트롤러를 올바르게 구성하면 모든 사용자가 포함된 간단한 JSON 배열 객체를 얻게 됩니다. 아주 멋진!
외부 API와 통신할 때도 동일한 원칙이 적용됩니다. Twitter에서 사용자의 최근 트윗을 가져오고 싶다고 가정해 보겠습니다. 당신이 해야 할 일은 Rails 애플리케이션에 Twitter의 API와 상호 작용하는 방법(즉, 자체 인증)을 알려주고, 요청을 보내고, 반환될 "트윗" 세트를 처리하는 것뿐입니다.
API 생성
Rails 애플리케이션을 프런트엔드 웹페이지용 순수 백엔드 API로 만들고 싶을 수도 있고, 프런트엔드에서 요청할 때 JSON을 보내는 방법을 배우고 싶을 수도 있습니다. 이 섹션에서는 인증 기능을 갖춘 완전한 RESTful API를 생성하는 방법을 다루지 않습니다. 이는 애플리케이션을 API로 처리하는 방법을 원활하게 소개합니다.
기초
Rails 애플리케이션이 HTML 대신 JSON을 반환하도록 하려면 컨트롤러에 그렇게 하도록 지시해야 합니다. 좋은 점은 사용자가 브라우저에서 정기적으로 요청하는지 아니면 명령줄을 통해 API에 액세스하는지에 따라 동일한 컨트롤러 작업이 다른 유형을 반환할 수 있다는 것입니다. 이는 example.xml 또는 example.json과 같은 요청된 파일의 확장자를 기반으로 어떤 유형의 요청이 이루어졌는지 결정합니다.
서버 로그를 확인하면 예상한 파일 형식에 대해 Rails가 어떻게 생각하는지 확인할 수 있습니다.
2013-12-02 15:21:08 -0800에 127.0.0.1에 대한 GET "/posts/new" 시작됨 PostsController#new에 의해 HTML로 처리
첫 번째 줄은 어떤 URL이 요청되었는지 알려주고, 두 번째 줄은 URL이 전송된 위치와 Rails가 이를 처리하는 방법을 알려줍니다. .json 확장자를 사용하는 경우 다음과 같습니다.
2013-12-04 12:02:01 -0800에 127.0.0.1에 대한 GET "/posts.json"을 JSON으로 PostsController#index에서 처리 시작했습니다.
테스트 애플리케이션을 실행 중인 경우 다른 URL을 요청해 보세요. 컨트롤러가 이를 처리할 수 없는 경우 오류가 발생할 수 있지만 Rails가 귀하의 요청을 이해하는 내용을 계속 확인할 수 있습니다.
JSON 또는 XML 렌더링
JSON 또는 XML을 사용하여 요청에 응답하기로 결정한 후에는 컨트롤러에 HTML 대신 JSON 또는 XML을 렌더링하도록 지시해야 합니다. 이를 수행하는 한 가지 방법은 #respond_to 메소드를 사용하는 것입니다.
클래스 UsersController< ApplicationController def index @users = User.all respond_to do |format| format.html # index.html.erb format.xml { render xml: @users } format.json { render json: @users } end end end
이 경우 #respond_to는 해당 렌더링 호출을 연결할 수 있는 형식 개체를 블록에 전달합니다. 아무것도 하지 않으면 표준 Rails 템플릿(이 예에서는 app/views/index.html.erb)을 사용하여 html이 렌더링됩니다.
#render 기능은 다양한 형식을 렌더링하는 방법을 이해할 만큼 똑똑합니다. key:json 을 전달하면 값(이 예에서는 @users )에서 #to_json을 호출합니다. 그러면 Ruby 객체가 요청 애플리케이션에 전달될 JSON 문자열로 변환됩니다.
이렇게 하면 API를 얻을 수 있습니다. 물론 멋진 일을 하고 싶다면 API를 만드는 것이 좀 더 복잡할 수 있지만 모든 것은 기본에 충실합니다.
반환된 속성 지정
User 개체와 함께 사용자의 이메일 주소를 반환하지 않도록 하려고 한다고 가정해 보겠습니다. 이 경우 반환될 속성을 변경하여 #to_json 메서드의 기능을 수정해야 합니다.
이전에는 단순히 #to_json 메서드를 해당 버전으로 재정의했지만 이제는 그럴 필요가 없습니다. 실제로 대신 #as_json 메서드를 재정의하게 됩니다. #as_json 메서드는 #to_json 메서드에서 사용되므로 수정하면 #to_json 의 결과가 암시적으로 변경되지만 다소 구체적인 방식으로 변경됩니다.
#to_json은 두 가지 작업을 수행합니다. 즉, #as_json을 실행하고 JSON으로 렌더링될 속성의 해시를 가져옵니다. 그런 다음 ActiveSupport::json.encode 를 사용하여 JSON으로 렌더링합니다. 따라서 #as_json을 수정하면 실제로 변경하려는 #to_json 메서드 부분에 대해 더 구체적으로 알 수 있습니다.
우리의 경우에는 필요한 속성만 반환하도록 모델에서 #as_json을 수정하여 이를 수행합니다.
# app/models/user.rb 클래스 사용자< ActiveRecord::Base # Вариант 1: Полное переопределение метода #as_json def as_json(options={}) { :name =>self.name ) # 이메일 필드를 포함하지 마세요 end # 옵션 2: 표준 방법을 사용합니다 #as_json def as_json(options=()) super(only: [:name]) end end
그런 다음 컨트롤러는 평소와 같이 JSON을 렌더링하면 됩니다(아래 예에서는 HTML 요청이 전송되었는지 여부에 관계없이 JSON이 항상 반환됩니다).
# app/controllers/users_controller.rb 클래스 UsersController< ApplicationController def index render json: User.all end end
#render를 사용할 때 #to_json을 직접 호출할 필요는 없습니다. 호출하면 됩니다.
때때로 Heroku는 오류 페이지를 올바르게 표시하기 위해 추가 단계가 필요할 수 있습니다. 구경하다. 먼저 app/public 디렉토리에서 정적 페이지를 제거해야 할 수도 있습니다.
외부로부터의 보안 확보
사용자가 로그인한 경우에만 API에 대한 액세스를 허용한다고 가정해 보겠습니다. 컨트롤러의 기존 인증은 이미 이 작업을 수행합니다. #before_action이 올바르게 설정되었는지 확인하세요(예: before_action:require_login). 로그인한 사용자와 로그인하지 않은 사용자 모두가 페이지를 볼 수 있지만 각각 다른 데이터를 볼 수 있는 기능이 필요할 수 있습니다. 인증되지 않은 사용자가 민감한 데이터를 얻기 위해 API 호출을 하는 것을 원하지 않습니다. 마찬가지로, 승인되지 않은 사용자가 특정 HTML 페이지를 방문하는 것을 허용하고 싶지 않습니다.
브라우저가 아닌 애플리케이션(예: 명령줄)의 요청을 처리하려는 경우 인증을 위해 브라우저 "쿠키"를 사용할 수 없습니다. 이것이 대부분의 API가 인증 프로세스의 일부로 기본 토큰을 사용하는 이유입니다. 다음 강의에서는 토큰에 대해 조금 더 이야기하겠습니다.
다음 단계
이제 Rails 애플리케이션을 사용하여 HTML뿐만 아니라 다른 형식도 렌더링할 수 있는 기술을 갖추게 되었습니다. 더 나아가 다른 개발자가 귀하의 플랫폼을 사용하여 무언가를 구축할 수 있도록 허용하려면(예를 들어 사용자로 인증하는 대신 프로그래밍 방식의 요청을 할 수 있도록) API 시스템을 훨씬 더 강력하게 만들어야 합니다. 여기서 모든 내용을 다루지는 않지만 다음 사항을 확인하세요.
- Building Awesome Rails API 기사에서는 장난감 애플리케이션에서 산업용 API 표준으로 전환하기 위한 여러 가지 최선의 접근 방식을 설명합니다.
서비스 지향 아키텍처
이제 SOA(서비스 지향 아키텍처)라는 아키텍처 접근 방식을 소개할 때입니다. 기본 아이디어는 귀하의 애플리케이션이 결제 시스템, 사용자 등록, 추천 모듈 등과 같은 많은 서비스로 구성된다는 것입니다. 하나의 기본 애플리케이션 내에 모든 것을 구축하는 대신 하위 시스템을 내부 API를 사용하여 서로 통신하는 완전히 독립적인 부분으로 나눕니다.
이는 여러 가지 이유로 좋습니다. 애플리케이션의 각 부분은 다른 부분의 작동 방식에 관심이 없고 해당 API를 통해 데이터를 요청하는 방법만 알고 있으므로 서비스 코드를 크게 변경할 수 있으며 나머지 애플리케이션은 이전처럼 작동합니다. 하나의 서비스를 다른 서비스로 완전히 교체할 수 있으며, 동일한 API 메서드를 사용하여 통신하는 한 매우 원활하게 진행됩니다. 직접 작성하는 대신 외부 API를 애플리케이션(예: 결제 시스템)의 일부로 사용할 수 있습니다. Rails 애플리케이션과 통신하는 Python 애플리케이션과 통신하는 PHP 애플리케이션을 만들 수 있으며 API를 사용하여 서로 통신하기 때문에 모든 것이 작동합니다.
일반적으로 애플리케이션의 각 부분을 가능한 한 독립적으로 만드는 것이 좋습니다. SOA의 개념은 애플리케이션의 다른 부분에 어떤 메서드를 노출할지 생각하게 하며, 이는 코드를 더 좋게 만들 수도 있습니다. 또한 애플리케이션의 각 주요 구성 요소가 독립적이라고 가정하면 문제를 훨씬 더 쉽게 격리하고 더 의미 있는 방식으로 오류를 처리할 수 있습니다.
전체 애플리케이션에 서비스 지향 아키텍처를 사용하는 것은 거대하고 복잡한 Ruby 스크립트를 더 큰 규모로 깔끔한 클래스와 메소드로 분할하는 것과 같습니다.
서비스 지향 아키텍처로 전환한 가장 유명한 사례 중 하나는 Amazon.com입니다. 2002년 어느 날, Jeff Bezos는 모든 작업 그룹이 SOA로 이동하지 않으면 해고되어야 한다고 직설적으로 말했습니다. 유명한 블로그 게시물내부 목적으로 의도되었지만 실수로 공개된 Google 직원은 SOA를 사용하여 Amazon의 힘에 대해 이야기했습니다. 훌륭한 읽기이므로 꼭 확인해 보세요. 하지만 Bezos의 편지의 주요 내용은 해당 게시물의 다음 인용문에 요약되어 있습니다.
1) 이제 모든 팀은 서비스 인터페이스를 통해 데이터와 기능을 제공합니다.
2) 팀은 이러한 인터페이스를 통해 서로 통신해야 합니다.
3) 다른 형태의 프로세스 간 통신은 금지됩니다. 직접 링크 금지, 다른 명령 데이터 직접 읽기 금지, 공유 메모리 모델 금지, 백도어 금지 등. 허용되는 유일한 상호 작용 방법은 네트워크를 통해 서비스 인터페이스에 액세스하는 것입니다.
4) 어떤 기술을 사용하는지는 중요하지 않습니다. HTTP, Corba, Pubsub, 독점 프로토콜 - 차이가 없습니다. 베조스는 상관하지 않습니다.
5) 모든 서비스 인터페이스는 예외 없이 초기에 외부에서 제어할 수 있도록 설계되어야 합니다. 즉, 회사 외부의 개발자에게 인터페이스를 제공할 수 있도록 팀에서 계획하고 설계해야 합니다. 예외 없음.
6) 이러한 요구 사항을 무시하는 사람은 해고됩니다.
SOA는 진지한 사업입니다. 물론, 그것을 사용할 때 발생하는 많은 문제가 있습니다. Amazon의 "교훈"에 대한 이 게시물을 확인하십시오. 그러나 엄청난 양의 이점이 있습니다.
스스로 장난감 앱을 구축하는 동안에는 SOA에 대해 크게 걱정하지 않을 것입니다. 그러나 IT 회사에 입사하게 되면 발생할 수 있는 문제이므로 익숙해지는 것이 좋습니다.
당신의 목표
- JSON 및 XML 렌더링에 대해 알아보려면 Rails 컨트롤러 가이드의 섹션 7을 읽어보세요.
- 볼 필요는 없지만(현재 준비한 것보다 조금 더 발전하기 때문에) 관심이 있으시면 강의 하단에 있는 추가 리소스 섹션에서 Railscasts를 살펴보세요. API의 이점.
결론
Javascript 과정을 진행하는 동안 귀하의 애플리케이션을 API로 더욱 긴밀하게 작업할 것입니다. 이 과정에서는 기본적으로 전체 HTML 페이지 대신 XML 또는 JSON 데이터를 렌더링하는 것과 관련된 더 나은 사용자 경험을 위해 AJAX 호출을 사용하는 여러 전체 스택 애플리케이션을 만듭니다. 그런 다음 Rails 애플리케이션에서 제공하는 API를 사용하여 데이터베이스에서 필요한 모든 데이터를 가져오지만 그렇지 않은 경우 클라이언트 측(브라우저)에서 실행되는 여러 단일 페이지 Javascript 애플리케이션을 생성합니다.
API를 이해하는 가장 좋은 방법은 API를 만들고 상호 작용하는 것입니다. 이는 우리 프로젝트에서 중점을 둘 것입니다.
API - 그게 뭐죠? 디코딩, 정의, 번역
API는 영어 약어입니다., 이는 다음을 의미합니다. ㅏ애플리케이션 피프로그래밍 나 ninterface - "응용 프로그래밍 인터페이스". 일반적으로 API는 서비스에 액세스하고 서비스에서 데이터를 요청할 수 있는 편리한 기능 집합입니다. 영어에서는 이 약어를 "hey-pi-ay"로 발음하지만, 러시아어를 사용하는 프로그래머들은 자신의 삶을 불필요하게 복잡하게 만들지 않고 "ápi"라고 말합니다.
API의 전형적인 예는 Yandex.maps입니다. 경험이 많든 적든 프로그래머나 웹마스터는 편리한 API 기능을 사용하여 필요한 설정으로 도시나 마을의 Yandex 지도를 자신의 웹사이트에 배치할 수 있습니다. Yandex는 완전히 무료로 제공하며 Yandex.Maps 웹사이트 사용자가 사용할 수 있는 거의 모든 지도 설정 세트를 포함합니다.
그 단어가 어디서 왔는지 알아냈나요? API, 간단한 단어, 번역, 기원 및 의미로 설명합니다.
동료의 작업을 더 쉽게 만들고 모든 Windows 프로그램에 범용 인터페이스를 제공하기 위해 Microsoft 프로그래머는 "응용 프로그래밍 인터페이스"라는 API를 만들었습니다.
이는 디렉토리 트리 표시, 파일 검색, 닫기, 최소화 및 최대화 버튼이 있는 표준 창 표시 등 프로그램에서 가장 자주 사용할 수 있는 기능 및 절차의 집합입니다. 결과적으로 Windows용 프로그램을 만드는 개발자는 프로그램 창, 폴더 선택 창 및 기타 유사한 기본 작업을 표시하기 위한 특수 서브루틴을 생각하고 개발할 필요가 없습니다. 간단히 kernel32.dll 또는 user32.dll을 호출하면 됩니다. 함수와 프로시저 API가 포함된 라이브러리에서 그에게 필요한 기능을 찾아내면 그녀가 그를 위해 모든 것을 직접 해줄 것입니다. 그러한 기능과 절차는 약 600개 정도입니다.
MS-DOS 운영 체제에는 API와 같은 것이 없었습니다. 이 운영 체제용 프로그램을 작성하는 사람은 화면에 이미지를 표시하고 사용자로부터 데이터를 수신하는 방법을 생각하고 구현해야 했습니다. 2. 그러한 가능성이 필요한 경우 파일 시스템을 통해 이동하여 그래픽을 그리기 시작합니다. 이로 인해 사용자 친화적인 인터페이스를 갖춘 프로그램을 개발하는 과정이 매우 노동 집약적인 과정이 되었습니다. 프로그램에 적합한 그래픽 인터페이스를 만드는 데 소요되는 시간과 노력이 프로그램 자체 알고리즘을 구현하는 데 드는 비용을 초과하는 경우가 많았습니다. . 소위 "콘솔" 응용 프로그램이 매우 일반적이라는 것은 아무것도 아닙니다. 즉, 인터페이스 없이 명령줄에서만 작동하는 프로그램입니다. 데이터는 동일한 명령줄에 입력되거나 지정된 파일에서 만들어졌습니다. 결과는 단순 텍스트 모드로 출력되었습니다.
Windows 운영 체제의 출현으로 프로그램의 모양과 정보를 입력하고 출력하는 편리한 방법을 개발하기 위한 프로그래머의 노력이 크게 촉진되었습니다. API 기능은 이미 Windows 3.0에서 사용되었습니다. 이제 프로그래머는 예를 들어 텍스트 입력 창이나 스크롤 막대를 만들고 싶다면 다른 기능과 마찬가지로 필요한 매개 변수를 사용하여 해당 창을 표시하는 함수에 대한 호출만 작성하면 됩니다. 그러한 창이나 막대를 다시 그리는 프로그램을 만들기 위해 엄청난 양의 코드를 도입하지 않고 자신의 프로그램을 작성한 언어로 작성했습니다(그러한 객체도 사용하는 다음 프로그램을 개발할 때 그는 그런 코드를 다시 사용하거나 이전 코드를 부분적으로 사용하여 이 새 프로그램의 요구 사항에 맞게 조정해 보세요. 따라서 API의 출현은 프로그래밍 기술에 획기적인 발전을 가져왔으며, 정보 입력 및 출력을 위한 표준 인터페이스 개체 프로그래밍과 같은 일상적인 세부 사항에 대해 걱정할 필요 없이 친숙하고 편리한 인터페이스로 필요한 프로그램을 훨씬 더 빠르게 만들 수 있게 되었습니다.
VBA(Visual Basic for Application) 언어에서는 인터프리터가 프로그램을 실행할 때 많은 함수와 API 프로시저가 스스로 호출되므로 텍스트 입력 및 출력 창을 표시하거나 화면에 기하학적 모양을 그리는 데 사용할 필요가 전혀 없습니다. 화면 및 기타 간단한 작업 - VBA는 필요에 따라 이를 호출하며 해당 프로그램은 이 언어의 적절한 기능만 사용해야 합니다. 그러나 때로는 내장된 VBA 기능에 유사점이 없거나 비합리적으로 또는 너무 느리게 작동하는 특정 작업이 필요한 경우가 있습니다. 예를 들어 디렉터리 트리 이미지(그림 5.1)가 있는 폴더 선택 창이나 파일 검색 프로그램(VBA 기능의 아날로그 - "Application.FileSearch" 개체 - 많은 수의 파일에서 너무 느리게 작동함)이 있습니다. 이러한 경우 VBA는 API 함수를 호출하는 기능을 제공합니다.
안타깝게도 VBA에서 API 함수를 사용하는 방법은 도움말에 문서화되어 있지 않으므로 사용 방법을 배우려면 사무용 프로그래밍에 대한 책이나 온라인 소스를 찾거나 API 함수에 대한 호출이 포함된 프로그램 코드를 분석해야 합니다.
대부분의 경우 Office용으로 프로그래밍할 때 API를 사용하지 않고도 작업을 수행할 수 있지만 때로는 API 함수를 호출하는 것만으로도 원하는 결과를 얻을 수 있습니다. Word 도구 모음의 단추를 마우스로 클릭할 때와 이 단추와 Shift 또는 Ctrl 키를 동시에 누를 때 서로 다른 매크로가 호출되도록 해야 한다고 가정해 보겠습니다. 다음은 이 작업을 수행하는 코드 조각입니다.
함수 GetAsyncKeyState Lib "user32.dll"(ByVal kState As Long)을 정수로 선언
GetAsyncKeyState(vbKeyShift 또는 vbKeyControl)
GetAsyncKeyState(vbKeyShift)인 경우
매크로1 호출: 하위 종료
ElseIf GetAsyncKeyState(vbKeyControl) Then
매크로2 호출: 하위 종료
첫 번째 줄은 VBA 프로그램에서 사용하기 위해 API 함수를 "예약"하는 것과 같습니다. GetAsyncKeyState 함수가 라이브러리(다른 프로그램에서만 사용하기 위한 프로그램이 포함된 파일) user32.dll에서 호출되고 키 번호가 이 함수에 전달되고 정수(즉, 0인 경우)를 반환하는 것을 볼 수 있습니다. 해당 숫자의 키는 누르지 않으며, 누르면 -32767 또는 1이 됩니다. VBA가 아닌 라이브러리에서 호출되는 모든 함수나 프로시저는 Declare 명령을 사용하여 예약해야 합니다.
명령의 vbKeyShift 문구는 Shift 키 코드(값은 16)를 대체하고 vbKeyControl은 이해하기 쉽도록 Control 키 코드를 대체합니다. "If...Then" 문의 구조는 명확한 것 같지만 3, 그렇지 않은 경우 VBA 도움말을 살펴보세요. 기억하시겠지만 매크로 이름 앞에 있는 호출 명령은 매크로를 실행한다는 의미입니다.
인터넷에는 API 4 전용 러시아 사이트가 있습니다. 이 기능 세트에 대해 자세히 알아보려면 해당 사이트를 방문하세요.
, 함수, 구조 또는 상수) 한 컴퓨터 프로그램이 다른 프로그램과 상호 작용할 수 있습니다. 일반적으로 일부 인터넷 프로토콜(예: RFC), 소프트웨어 프레임워크(프레임워크) 또는 운영 체제 기능 호출 표준에 대한 설명에 포함됩니다. 별도의 소프트웨어 라이브러리나 운영 체제 서비스로 구현되는 경우가 많습니다. 프로그래머가 모든 종류의 응용 프로그램을 작성할 때 사용합니다.
애플리케이션 통합 수단으로서의 API
API는 프로그램(모듈, 라이브러리)이 제공하는 기능을 정의하는 반면, API를 사용하면 이 기능이 정확히 어떻게 구현되는지 추상화할 수 있습니다.
프로그램(모듈, 라이브러리)이 블랙박스로 간주된다면 API는 이 박스의 사용자가 사용할 수 있고 돌리고 당길 수 있는 "핸들" 세트입니다.
소프트웨어 구성 요소는 API를 통해 서로 상호 작용합니다. 이 경우 구성 요소는 일반적으로 계층 구조를 형성합니다. 상위 수준 구성 요소는 하위 수준 구성 요소의 API를 사용하고, 더 낮은 수준 구성 요소의 API를 사용합니다.
인터넷을 통한 데이터 전송 프로토콜은 이 원칙에 따라 구축되었습니다. 표준 프로토콜 스택(OSI 네트워크 모델)에는 7개 계층(물리적 비트 전송 계층부터 HTTP 및 IMAP 프로토콜과 같은 애플리케이션 프로토콜 계층까지)이 포함되어 있습니다. 각 계층은 이전(“하위”) 데이터 전송 계층의 기능을 사용하고, 다음(“상위”) 수준에 필요한 기능을 제공합니다.
프로토콜 개념은 API 개념과 의미가 유사하다는 점에 유의하는 것이 중요합니다. 둘 다 기능의 추상화입니다. 첫 번째 경우에만 데이터 전송에 대해 이야기하고 두 번째 경우에는 애플리케이션의 상호 작용에 대해 이야기합니다.
함수 및 클래스 라이브러리 API에는 설명이 포함되어 있습니다. 서명그리고 함수의 의미론.
기능 서명
때로는 구별하기도 한다 통화 서명그리고 구현 서명기능. 호출 시그니처는 일반적으로 주어진 함수의 범위 시그니처, 함수 이름, 호출의 실제 인수 유형 순서 및 함수 유형을 고려하여 함수 호출의 구문 구조에서 컴파일됩니다. 결과. 구현 시그니처에는 일반적으로 함수 선언 구문 구조의 일부 요소(함수 범위 지정자, 해당 이름, 일련의 형식 인수 유형)가 포함됩니다.
예를 들어, C++ 프로그래밍 언어에서 간단한 함수는 해당 이름과 해당 언어의 함수 시그니처를 구성하는 인수 유형의 시퀀스로 컴파일러에 의해 고유하게 식별됩니다. 함수가 특정 클래스의 메서드인 경우 클래스 이름도 시그니처에 포함됩니다.
소프트웨어 산업에서 표준 기능을 위한 공통 표준 API는 공통 API를 사용하는 모든 프로그램이 동일하게 또는 적어도 일반적으로 친숙한 방식으로 작동하도록 보장하기 때문에 중요한 역할을 합니다. GUI API의 경우 이는 프로그램이 유사한 사용자 인터페이스를 갖게 되어 새로운 소프트웨어 제품을 더 쉽게 배울 수 있음을 의미합니다.
반면에 서로 다른 운영 체제의 API 차이로 인해 플랫폼 간에 애플리케이션을 포팅하는 것이 매우 어렵습니다. 이러한 복잡성을 해결하는 다양한 방법이 있습니다. "중간" API(wxWidgets, GTK 등 GUI API) 작성, 한 OS의 시스템 호출을 다른 OS(Wine, cygwin 등과 같은 런타임)의 시스템 호출에 매핑하는 라이브러리 작성 등이 있습니다. .), 프로그래밍 언어의 코딩 표준 도입(예: C 언어의 표준 라이브러리), 다양한 플랫폼(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
운영체제
Wikipedia의 정의에 따르면 API는 외부 소프트웨어 제품에 사용하기 위해 애플리케이션(라이브러리, 서비스)에서 제공하는 미리 만들어진 클래스, 프로시저, 함수, 구조 및 상수의 집합입니다. 프로그래머가 모든 종류의 응용 프로그램을 작성하는 데 사용됩니다.
그러나 Wikipedia의 대부분은 많은 사람들이 이해할 수 없기 때문에 API가 무엇인지, API가 일반적으로 무엇을 위해 만들어지고 어떻게 사용되는지 일반인의 용어로 설명하려고 노력할 것입니다.
API는 완전히 다르지만, 예를 들어 매장 네트워크가 있고 공통 데이터베이스가 하나만 있는 상황을 선택했습니다. 당신이 제휴 프로그램을 소유하고 있다고 상상해보십시오. 제휴 프로그램은 다음 원칙에 따라 작동합니다. 개인이 제휴 프로그램에 등록하고 스토어 엔진을 받습니다. 그런 다음 그는 자신의 호스팅에 이 스토어를 설치하고 작업을 시작할 수 있습니다. 하지만 이 스토어의 모든 데이터는 우리 데이터베이스에서 가져옵니다. 즉, 각 파트너에게 소중한 데이터베이스에 대한 액세스 권한을 부여해야 합니다. 이것이 얼마나 위험한지 상상할 수 있습니까? 결국, 모든 파트너 매장이 이를 사용할 수 있도록 외부에서 데이터베이스에 대한 액세스를 열어야 합니다. 귀하의 액세스 데이터가 범죄자의 손에 들어가면 어떻게 되나요?
이것이 API가 우리를 도울 곳입니다. 데이터베이스에 대한 액세스 권한을 부여하는 대신 파트너 매장이 정보를 수신할 수 있는 API를 간단히 만들겠습니다. 이렇게 하면 API 스크립트만 데이터베이스와 작동하고 상점은 이 스크립트와 작동합니다.
어떻게 작동하나요?
예를 들어 상점에서 API에 요청을 보냅니다.
http://ourapi.com/get_books?limit=20
우리 API는 한계 매개변수를 20으로 전달했기 때문에 20권으로 구성된 도서 목록을 제공해야 한다는 것을 이해합니다. 스크립트(API)는 데이터베이스에 요청하고 도서 목록을 수신하여 데이터베이스에 반환합니다. 특정 형식으로 저장합니다(실제로는 표시만 합니다). API가 정보를 반환하는 형식은 무엇이든 될 수 있으며, 가장 중요한 것은 매장이 이를 이해한다는 것입니다. 이는 JSON, 직렬화된 배열 또는 XML일 수 있습니다. 이것은 더 이상 중요하지 않습니다. 가장 중요한 것은 원리를 이해하는 것입니다.
API가 스스로 이해하는 명령 세트를 정의합니다. 예를 들어, 우리의 경우 책 목록 가져오기, 카테고리 목록 가져오기, 인기 책 가져오기, 새 책 가져오기 등과 같은 명령이 될 수 있습니다. 이렇게 하면 공격자가 우리 API에 액세스할 수 있는 기회를 얻더라도 그가 할 수 있는 일은 도서 목록을 얻는 것뿐이며 이는 우리 데이터베이스에 어떤 위협도 가하지 않습니다.
간단한 예를 통해 API가 무엇인지 설명할 수 있었으면 좋겠습니다. 궁금한 점이 있으면 댓글이나 포럼에 질문해 주세요. 기꺼이 해결하도록 도와드리겠습니다.