소프트웨어 개발을 배우기 전에 API는 일종의 맥주처럼 들렸습니다.
오늘날 저는이 용어를 너무 자주 사용하여 최근에 술집에서 API를 주문하려고했습니다.
바텐더의 응답은 404 : 리소스를 찾을 수 없습니다.
저는이 용어가 의미하는 바에 대해 다소 모호하거나 잘못된 생각을 가지고있는 기술 및 기타 분야에서 일하는 많은 사람들을 만납니다.
기술적으로 API는 Application Programming Interface를 나타냅니다 . 어느 시점에서 대부분의 대기업은 고객 또는 내부 사용을 위해 API를 구축했습니다.
하지만 평범한 영어로 API를 어떻게 설명합니까? 그리고 개발과 비즈니스에 사용되는 것보다 더 넓은 의미가 있습니까? 먼저 웹 자체가 작동하는 방식을 살펴 보겠습니다.
WWW 및 원격 서버
웹에 대해 생각할 때, 연결된 서버 의 대규모 네트워크를 상상 합니다.
인터넷의 모든 페이지는 원격 서버에 저장됩니다. 원격 서버는 결국 그다지 신비 롭지 않습니다. 요청 처리에 최적화 된 원격 컴퓨터의 일부일뿐입니다.
전체 웹 사이트를 웹에 제공 할 수있는 랩톱에서 서버를 가동 할 수 있습니다 (사실 로컬 서버는 엔지니어가 웹 사이트를 공개하기 전에 웹 사이트를 개발하는 데 사용하는 것입니다).
브라우저에 www.facebook.com을 입력하면 Facebook의 원격 서버로 요청이 전송됩니다. 브라우저가 응답을 받으면 코드를 해석하고 페이지를 표시합니다.
클라이언트 라고도하는 브라우저에게 Facebook의 서버는 API입니다. 즉, 웹 페이지를 방문 할 때마다 일부 원격 서버의 API와 상호 작용합니다.
API는 원격 서버와 동일하지 않으며 요청을 수신하고 응답을 보내는 서버의 일부입니다 .
고객에게 서비스를 제공하는 방법으로서의 API
API를 제품으로 패키징하는 회사에 대해 들어 보셨을 것입니다. 예를 들어 Weather Underground는 날씨 데이터 API에 대한 액세스 권한을 판매합니다.
예제 시나리오 : 소규모 비즈니스의 웹 사이트에는 고객이 약속에 등록하는 데 사용되는 양식이 있습니다. 고객에게 해당 약속에 대한 세부 정보가 포함 된 Google 캘린더 일정을 자동으로 만들 수있는 기능을 제공하려고합니다.
API 사용 : 아이디어는 주어진 세부 정보로 이벤트를 생성하도록 요청하여 웹 사이트의 서버가 Google 서버와 직접 통신하도록하는 것입니다. 그러면 서버가 Google의 응답을 수신하고 처리 한 다음 사용자에게 확인 메시지와 같은 관련 정보를 브라우저에 다시 보냅니다.
또는 브라우저는 종종 서버를 우회하여 Google 서버에 직접 API 요청을 보낼 수 있습니다.
이 Google 캘린더의 API는 다른 원격 서버의 API와 어떻게 다릅니 까?
기술적 인 측면 에서 차이점은 요청 형식과 응답입니다.
전체 웹 페이지를 렌더링하기 위해 브라우저는 표현 코드가 포함 된 HTML 로 응답을 예상하고 Google 캘린더의 API 호출은 JSON 과 같은 형식으로 데이터를 반환합니다 .
웹 사이트의 서버가 API 요청을하는 경우 웹 사이트의 서버는 클라이언트입니다 (웹 사이트를 탐색하는 데 사용할 때 브라우저가 클라이언트 인 것과 유사 함).
사용자 관점에서 API를 사용하면 웹 사이트를 떠나지 않고도 작업을 완료 할 수 있습니다.
대부분의 최신 웹 사이트는 최소한 일부 타사 API를 사용합니다.
라이브러리 나 서비스의 형태에 관계없이 많은 문제에 이미 타사 솔루션이 있습니다. 기존 솔루션을 사용하는 것이 더 쉽고 안정적입니다.
개발 팀이 API를 통해 서로 통신하는 여러 서버로 애플리케이션을 분할하는 것은 드문 일이 아닙니다. 기본 응용 프로그램 서버에 대한 도우미 기능을 수행하는 서버를 일반적으로 마이크로 서비스 라고합니다 .
요약하면, 회사가 고객에게 API를 제공한다는 것은 순수한 데이터 응답을 반환하는 전용 URL 집합을 구축했음을 의미 합니다. 즉 , 응답에는 사용자가 예상 할 수있는 프레젠테이션 오버 헤드가 포함되지 않습니다. 웹 사이트와 같은 그래픽 사용자 인터페이스 .
브라우저로 이러한 요청을 할 수 있습니까? 종종 그렇습니다. 실제 HTTP 전송은 텍스트로 이루어지기 때문에 브라우저는 항상 응답을 표시하기 위해 최선을 다합니다.
예를 들어 액세스 토큰이 없어도 브라우저에서 직접 GitHub의 API에 액세스 할 수 있습니다. 다음은 브라우저 (//api.github.com/users/petrgazarov)에서 GitHub 사용자의 API 경로를 방문 할 때받는 JSON 응답입니다.
{ "login": "petrgazarov", "id": 5581195, "avatar_url": "//avatars.githubusercontent.com/u/5581195?v=3", "gravatar_id": "", "url": "//api.github.com/users/petrgazarov", "html_url": "//github.com/petrgazarov", "followers_url": "//api.github.com/users/petrgazarov/followers", "following_url": "//api.github.com/users/petrgazarov/following{/other_user}", "gists_url": "//api.github.com/users/petrgazarov/gists{/gist_id}", "starred_url": "//api.github.com/users/petrgazarov/starred{/owner}{/repo}", "subscriptions_url": "//api.github.com/users/petrgazarov/subscriptions", "organizations_url": "//api.github.com/users/petrgazarov/orgs", "repos_url": "//api.github.com/users/petrgazarov/repos", "events_url": "//api.github.com/users/petrgazarov/events{/privacy}", "received_events_url": "//api.github.com/users/petrgazarov/received_events", "type": "User", "site_admin": false, "name": "Petr Gazarov", "company": "PolicyGenius", "blog": "//petrgazarov.com/", "location": "NYC", "email": "[email protected]", "hireable": null, "bio": null, "public_repos": 23, "public_gists": 0, "followers": 7, "following": 14, "created_at": "2013-10-01T00:33:23Z", "updated_at": "2016-08-02T05:44:01Z"}브라우저가 JSON 응답을 제대로 표시 한 것 같습니다. 이와 같은 JSON 응답을 코드에서 사용할 수 있습니다. 이 텍스트에서 데이터를 추출하는 것은 쉽습니다. 그런 다음 데이터로 원하는 것을 할 수 있습니다.
A는 "응용 프로그램"입니다.
마무리를 위해 API의 몇 가지 예를 더 살펴 보겠습니다.
"응용 프로그램"은 많은 것을 가리킬 수 있습니다. 다음은 API 컨텍스트에서 몇 가지입니다.
- 고유 한 기능을 가진 소프트웨어입니다.
- 전체 서버, 전체 앱 또는 앱의 작은 부분.
기본적으로 환경과 구별 될 수있는 모든 소프트웨어는 API에서 "A"가 될 수 있으며 일종의 API도 가질 수 있습니다.
코드에서 타사 라이브러리를 사용하고 있다고 가정 해 보겠습니다. 코드에 통합되면 라이브러리가 전체 앱의 일부가됩니다. 별개의 소프트웨어이므로 라이브러리에는 나머지 코드와 상호 작용할 수있는 API가있을 수 있습니다.
또 다른 예가 있습니다. 객체 지향 디자인 에서 코드는 객체로 구성됩니다. 애플리케이션에는 서로 상호 작용할 수있는 수백 개의 개체가 정의되어있을 수 있습니다.
각 개체에는 API ( 애플리케이션의 다른 개체와 상호 작용하는 데 사용하는 공용 메서드 및 속성 집합)가 있습니다.
An object may also have inner logic that is private, meaning that it’shiddenfrom the outside scope (and not an API).
From what we have covered, I hope you take away the broader meaning of API as well as the more common uses of the term today.
Interesting Resources (stuff that I left out but is still very cool):
A great youtube video on DNS (Domain Name System)
HTTP protocol basics
An Awesome Khan Academy video on Object Oriented Design Principles