상상코딩

1. REST API

 1) 개요

• 웹 애플리케이션에서는 HTTP 메서드를 이용해 서버와 통신한다
  - GET을 통해 웹 페이지나 데이터를 요청한다
  - POST로 새로운 글이나 데이터를 전송한다
  - DELETE로 저장된 글이나 데이터를 삭제한다
• 클라이언트와 서버가 HTTP 통신을 할 때는 어떤 요청을 보내고 받느냐에 따라 메서드의 사용이 달라진다
• REST API에서 REST는 “Representational State Transfer”의 약자이다
  - 로이 필딩의 박사학위 논문에서 웹(http)의 장점을 최대한 활용할 수 있는 아키텍처로써 처음 소개되었다
• REST API는 웹에서 사용되는 데이터나 자원(Resource)을 HTTP URI로 표현하고, HTTP 프로토콜을 통해 요청과 응답을 정의하는 방식이다

 2) 역활

• 클라이언트와 서버 사이에는 데이터와 리소스를 요청하고 요청에 따른 응답을 전달하기 위한 도구 필요하다
• 도구를 통해 클라이언트는 서버에 필요한 것을 요청하고, 이에 대한 응답을 다시 서버에서 클라이언트로 전송할 수 있다
• HTTP 프로토콜 기반으로 요청과 응답에 따라 리소스를 주고받는 작업을 API가 수행해야 한다
  - 클라이언트와 서버 간에 서로 잘 알아볼 수 있도록 작성하는 것이 중요하다

2. REST API를 디자인하는 방법

• REST API를 작성에는 몇 가지 지켜야 할 규칙들이 있다
• 로이 필딩이 논문에서 제시한 REST 방법론을 보다 더 실용적으로 적용하기 위해 레오나르드 리차드슨은 REST API를 잘 적용하기 위한 4단계 모델을 만들었다
  - 로이 필딩은 이 모델의 모든 단계를 충족해야 REST API라고 부를 수 있다고 주장했다
  -  2단계까지만 적용해도 좋은 API 디자인이라고 볼 수 있고, 이런 경우 HTTP API 라고 한다
  - 리차드슨의 REST 성숙도 모델은 총 4단계(0~3단계)로 나누어진다

 1) REST 성숙도 모델 - 0단계

• 0단계에서는 HTTP 프로토콜을 사용하기만 해도 된다
  - 0단계의 경우에는 해당 API를 REST API라고 할 수는 없다
  - 0단계는 좋은 REST API를 작성하기 위한 기본 단계이다
• 허준이라는 의사의 예약 가능한 시간을 확인하고, 어떤 특정 시간에 예약하는 상황의 예제
  - HTTP 프로토콜을 사용하고 있다
  - 단순히 HTTP 프로토콜을 사용하는 것이 REST API의 출발점이다

 2) REST 성숙도 모델 - 1단계

• 1단계에서는 개별 리소스와의 통신을 준수해야 한다
• REST API는 웹에서 사용되는 모든 데이터나 자원(Resource)을 HTTP URI로 표현한다
  - 모든 자원은 개별 리소스에 맞는 엔드포인트(Endpoint)를 사용해야 한다
  - 모든 자원은 요청하고 받은 자원에 대한 정보를 응답으로 전달해야 한다
• 0단계에서는 모든 요청에서 엔드포인트로 /appointment 를 사용하였다
• 1단계에서는 요청하는 리소스가 무엇인지에 따라 각기 다른 엔드포인트로 구분하여 사용해야 한다
• 1단계 예제
  - 예약 가능 시간 확인이라는 요청의 응답으로 받게 되는 자원(리소스)은 허준이라는 의사의 예약 가능 시간대이다
   : 예약 가능 시간 확인 요청 시 /doctors/허준이라는 엔드포인트를 사용하였다
  - 특정 시간에 예약하게 되면, 실제 slot이라는 리소스의 123이라는 id를 가진 리소스가 변경된다
   : 특정 시간 예약이라는 요청에서는 /slots/123으로 실제 변경되는 리소스를 엔드포인트로 사용하였다

• 어떤 리소스를 변화시키는지 혹은 어떤 응답이 제공되는지에 따라 각기 다른 엔드포인트를 사용해야 한다
  - 적절한 엔드포인트를 작성하는 것이 중요하다
  - 엔드포인트 작성 시에는 동사, HTTP 메서드, 어떤 행위에 대한 단어 사용은 지양한다
  - 리소스에 집중된 명사 형태의 단어로 작성하는 것이 적당하다
• 요청에 따른 응답으로 리소스를 전달할 때에도 사용한 리소스에 대한 정보와 리소스 사용에 대한 성공/실패 여부를 반환해야 한다
  - 김코딩 환자가 허준 의사에게 9시에 예약을 진행하였으나, 해당 시간에 예약이 불가능할 경우에는 리소스 사용에 대한 실패 여부를 포함한 응답을 받아야 한다

 3) REST 성숙도 모델 - 2단계

• 2단계에서는 CRUD에 맞게 적절한 HTTP 메서드를 사용하는 것에 중점을 둔다
• 0단계와 1단계 예시에서는 모든 요청을 CRUD에 상관없이 POST로 하고 있다
  - REST 성숙도 모델 2단계에 따르면 CRUD에 따른 적합한 메서드를 사용한 것이 아니다
• 예약 가능 시간 확인은 예약 가능한 시간을 조회(READ)하는 행위를 의미한다
  - 조회(READ)하기 위해서는 GET 메서드를 사용하여 요청을 보낸다
  - GET 메서드는 body를 가지지 않기 때문에 query parameter를 사용하여 필요한 리소스를 전달한다
• 특정 시간 예약은 해당 특정 시간에 예약을 생성(CREATE)한다는 것과 같다
  - 예약을 생성(CREATE)하기 위해서는 POST 메서드를 사용하여 요청을 보내는 것이 적당하다
• 2단계에서는 POST 요청에 대한 응답이 어떻게 반환되는지도 중요하다
  - 응답은 새롭게 생성된 리소스를 보내주기 때문에, 응답 코드도 201 Created 로 명확하게 작성해야 한다
  - 관련 리소스를 클라이언트가 Location 헤더에 작성된 URI를 통해 확인할 수 있어야 완벽하게 REST 성숙도 모델의 2단계를 충족한 것이다

※ 메서드 사용 규칙

• GET 메서드는 서버의 데이터를 변화시키지 않는 요청에 사용해야 한다
• POST 메서드는 요청마다 새로운 리소스를 생성한다
• PUT 메서드는 요청마다 같은 리소스를 반환한다
  - 요청마다 같은 리소스를 반환하는 특징을 멱등(idempotent)하다고 한다
  - 멱등성을 가지는 메서드 PUT 과 그렇지 않은 POST는 구분하여 사용해야 한다
• PUT 과 PATCH 도 구분하여 사용해야한다
  - PUT은 교체의 용도로 사용한다
  - PATCH는 수정의 용도로 사용한다
• HTTP request methods : https://developer.mozilla.org/en-US/docs/Web/HTTP/Methods 

 4) REST 성숙도 모델 - 3단계

• 3단계는 HATEOAS(Hypertext As The Engine Of Application State)라고 표현되는 하이퍼미디어 컨트롤을 적용한다
• 3단계의 요청은 2단계와 동일하다
• 3단계의 응답은 리소스의 URI를 포함한 링크 요소를 삽입하여 작성하는 것이 다르다
• 응답에 들어가게 되는 링크 요소는 응답을 받은 다음에 할 수 있는 다양한 액션들을 위해 많은 하이퍼미디어 컨트롤을 포함하고 있다

• 응답 내에 새로운 링크를 넣어 새로운 기능에 접근할 수 있도록 하는 것이 3단계의 중요 포인트이다
  - 예약 가능 시간을 확인한 후에는 그 시간대에 예약을 할 수 있는 링크를 삽입할 수 있다
  - 특정 시간에 예약을 완료하고 나서 예약을 다시 확인할 수 있도록 링크를 작성할 수 있다

▶ 5가지의 기본적인 REST API 디자인 가이드 : https://blog.restcase.com/5-basic-rest-api-design-guidelines/

▶ 호주 정부 - API 설계 표준 : https://api.gov.au/sections/definitions.html#api 

▶ API 디자인 가이드 : https://cloud.google.com/apis/design?hl=ko 

▶ Microsoft REST API Guidelines : https://github.com/Microsoft/api-guidelines/blob/master/Guidelines.md 

1. HTTP(HyperText Transfer Protocol)

• HTML과 같은 문서를 전송하기 위한 Application Layer 프로토콜이다
• HTTP는 웹 브라우저와 웹 서버의 소통을 위해 디자인되었다
• 전통적인 클라이언트-서버 모델에서 클라이언트가 HTTP messages 양식에 맞춰 요청을 보내면, 서버도 HTTP messages 양식에 맞춰 응답한다
• HTTP는 특정 상태를 유지하지 않는 특징이 있다 (무상태성(Stateless))

2. HTTP message

 1) 개요

• 클라이언트와 서버 사이에서 데이터가 교환되는 방식이다
• HTTP messages에는 요청(Requests) 과 응답(Responses) 의 두 가지 유형이 있다
• HTTP messages는 몇 줄의 텍스트 정보로 구성된다
• 개발자가 직접 작성하지 않아도 구성 파일, API, 기타 인터페이스에서 HTTP messages를 자동으로 완성한다
• HTTP 메시지의 시작 줄과 HTTP 헤더를 묶어서 요청 헤드(head)라고 한다
• HTTP 메시지의 페이로드는 본문(body)이라고 한다

 2) 구성

• start line
  - 요청이나 응답의 상태를 나타내며, 항상 첫 번째 줄에 위치한다
  - 응답에서는 status line이라고 한다
• HTTP headers
  - 요청을 지정하거나, 메시지에 포함된 본문을 설명하는 헤더의 집합이다
• empty line
  - 요청에 대한 모든 메타 정보가 전송되었음을 알리고, 헤더와 본문을 구분하는 빈 줄을 삽입한다
• body
  - 요청과 관련된 데이터나 응답과 관련된 데이터 또는 문서를 포함하며, 요청과 응답의 유형에 따라 선택적으로 사용한다

3. 요청(Requests)

 1) Start line

• 클라이언트가 서버에 보내는 메시지이다
• 세가지 요소를 가지고 있다
• 수행할 작업(GET, PUT, POST 등)이나 방식(HEAD or OPTIONS)을 설명하는 HTTP method를 나타낸다
  - GET method는 리소스를 받아 온다
  - POST method는 데이터를 서버로 전송한다
• 요청 대상(일반적으로 URL이나 URI) 또는 프로토콜, 포트, 도메인의 절대 경로는 요청 컨텍스트(context)에 작성된다
• 요청 형식은 HTTP method 마다 다르다
  - origin 형식
   : ?와 쿼리 문자열이 붙는 절대 경로이다
   : POST, GET, HEAD, OPTIONS 등의 method와 함께 사용한다
   : POST / HTTP 1.1GET /background.png HTTP/1.0HEAD /test.html?query=alibaba HTTP/1.1OPTIONS /anypage.html HTTP/1.0
  
  - absolute 형식
   : 완전한 URL 형식이다
   : 프록시에 연결하는 경우 대부분 GET method와 함께 사용한다
   : GET http://developer.mozilla.org/en-US/docs/Web/HTTP/Messages HTTP/1.1
  
  - authority 형식
   : 도메인 이름과 포트 번호로 이루어진 URL의 권한요소(authority component) 이다
   : HTTP 터널을 구축하는 경우, CONNECT와 함께 사용할 수 있다
   : CONNECT developer.mozilla.org:80 HTTP/1.1
  
  - asterisk 형식
   : OPTIONS 와 함께 별표'*' 하나로 서버 전체를 표현한다
   : OPTIONS * HTTP/1.1
• HTTP 버전에 따라 HTTP message의 구조가 달라지므로 start line에 HTTP 버전을 함께 입력한다

 2) Headers

• 헤더의 기본 구조는 헤더 이름(대소문자 구분이 없는 문자열), 콜론( : ), 값  으로 되어 있다
• headers 는 여러 종류가 있으며, 아래의 그룹으로 나눌 수 있다
  - General headers
   : 메시지 전체에 적용되는 헤더이다
   : body를 통해 전송되는 데이터와는 관련이 없는 헤더입니다.
  
  - Request headers
   : fetch를 통해 가져올 리소스나 클라이언트 자체에 대한 자세한 정보를 포함하는 헤더이다
   : User-Agent, Accept-Type, Accept-Language과 같은 헤더는 요청을 보다 구체화한다
   : Referer처럼 컨텍스트를 제공하거나 If-None과 같이 조건에 따라 제약을 추가할 수 있다
  
  - Representation headers
   : Entity headers라고 부르기도 한다
   : Content-Length 와 같은 헤더는 요청 본문에 적용된다
   : body에 담긴 리소스의 정보(콘텐츠 길이, MIME 타입 등)를 포함하는 헤더이다
   : body가 없는 경우 전송되지 않는다

3) Body

• 요청의 body는 HTTP messages 구조의 마지막에 위치한다
• 모든 요청에 body가 필요하지는 않다
• GET, HEAD, DELETE, OPTIONS처럼 서버에 리소스를 요청하는 경우에는 본문이 필요하지 않다
• POST나 PUT과 같은 일부 요청은 데이터를 업데이트하기 위해 사용한다
• body는 다음과 같이 두 종류로 나눌 수 있습니다.
  - Single-resource bodies(단일-리소스 본문)
   : 헤더 두 개(Content-Type 과 Content-Length)로 정의된 단일 파일로 구성된다
  
  - Multiple-resource bodies(다중-리소스 본문)
   : 여러 파트로 구성되며, 각 파트마다 다른 정보를 가진다
   : HTML form 과 관련이 있다

4. 응답(Responses)

 1) Status line

• 응답의 첫 줄은 Status line이라고 한다
• HTTP/1.1 404 Not Found. 처럼 구성된다
• 다음의 정보를 포함한다
  - 현재 프로토콜의 버전
   : 보통 HTTP/1.1 이다
  
  - 상태 코드
   : 요청의 결과(성공여부)를 나타낸다
   : 200, 302, 404 등...
  
  - 상태 텍스트
   : 상태 코드에 대한 설명을 간결하게 나타낸다

 2) Headers

• 응답의 HTTP headers는 요청 헤더와 동일한 구조를 가진다
• 헤더 이름(대소문자 구분이 없는 문자열), 콜론( : ), 값 
• 값은 헤더에 따라 다르다
• 요청의 헤더처럼 그룹으로 나눌 수 있다
  - General headers
   : 메시지 전체에 적용되는 헤더이다
   : body를 통해 전송되는 데이터와는 관련이 없는 헤더이다
  
  - Response headers
   :위치 또는 서버 자체에 대한 정보(이름, 버전 등)와 같이 응답에 대한 부가적인 정보를 갖는 헤더이다
   : Vary, Accept-Ranges와 같이 상태 줄에 넣기에는 공간이 부족했던 추가 정보를 제공한다
  
  - Representation headers
   : Entity headers라고 부르기도 한다
   : body에 담긴 리소스의 정보(콘텐츠 길이, MIME 타입 등)를 포함하는 헤더이다

 3) Body

※ 참조

▶ HTTP 에러 코드

HTTP response status codes - HTTP | MDN (mozilla.org)

▶ HTTP 정의

HTTP - 위키백과, 우리 모두의 백과사전 (wikipedia.org)

▶ REST API

5 Basic REST API Design Guidelines (restcase.com)

▶ 상태코드

https://docs.oracle.com/cd/E17802_01/products/products/servlet/2.3/javadoc/javax/servlet/http/HttpServletResponse.html

1. URL(Uniform Resource Locator)

• 네트워크 상에서 웹 페이지, 이미지, 동영상 등의 파일이 위치한 정보를 나타낸다
• URL은 scheme, hosts, url-path로 구분할 수 있다
• scheme은 통신 방식(프로토콜)을 결정하며, 일반적인 웹 브라우저에서는 http(s)를 사용한다
• hosts는 웹 서버의 이름이나 도메인, IP를 사용하며 주소를 나타낸다
• url-path는 웹 서버에서 지정한 루트 디렉토리부터 시작하여 웹 페이지, 이미지, 동영상 등이 위치한 경로와 파일명을 나타낸다
• 브라우저로 파일을 찾아야 할 경우 'file://localhost/파일위치 디렉토리 주소' 를 사용하여 찾을 수 있다

2. URI(Uniform Resource Identifier)

• URL의 기본 요소인 scheme, hosts, url-path에 query, bookmark를 추가한다
• query는 웹 서버에 보내는 추가적인 질문이다
• http://www.google.com:80/search?q=Java 를 브라우저의 검색창에 입력하면, 구글에서 Java를 검색한 결과가 나타난다
• 브라우저의 검색창을 클릭하면 나타나는 주소가 URI이다
• URI는 URL을 포함하는 상위개념으로 URL은 URI와 같을 수 있지만, URI는 URL과 같을 수 없다

※ http://www.google.com:80/search?q=Java 구분

3. IP(Internet Protocol)

• 인터넷상에서 사용하는 주소체계를 의미한다
• 인터넷에 연결된 모든 PC는 IP 주소체계를 따라 네 개의 숫자 그룹으로 구분된다
• 네 덩이의 숫자로 구분된 IP 주소체계를 IPv4라고 한다
• IPv4(Internet Protocol version 4)는 IP 주소체계의 네 번째 버전을 나타낸다
• IPv4의 각각의 숫자그룹은 0부터 255까지 사용 가능하다
• 4개의 숫자그룹을 사용하면  2^(32)인 약 43억 개의 IP 주소를 가질 수 있다

• 용도가 정해져 있는 IP 주소도 있다

• 개인용 컴퓨터의 보급이 증가하여  IPv4의 주소가 고갈 단계에 도달하여 IPv6를 공식화 하였다
•  IPv6은 128비트 주소를 사용하여 이론적으로 2^(128) 개 주소를 가질 수 있다
• IPv6 주소는 각각 콜론으로 구분된 4개의 16진수로 구성된 8개의 그룹으로 표시된다

4. PORT

• IP 주소가 접속할 수 있는 통로를 의미한다
• 포트 번호는 0~ 65,535 까지 사용할 수 있다
• 0 ~ 1024번 까지의 포트 번호는 주요 통신을 위한 규약에 따라 이미 정해져 있다
• 알아두어야 할 포트 번호

5. 도메인(Domain)

• IP 주소에 특정한 이름을 부여한 것을 도메인이라 한다
• 도메인은 일정 기간동안 대여하여 사용한다

6. DNS(Domain Name System)

• 호스트의 도메인 이름을 IP 주소로 변환하거나 반대의 경우를 수행할 수 있도록 개발된 데이터베이스 시스템이다
• 네트워크에는 DNS서버가 별도로 존재한다
• 브라우저에 요청된 도메인을 검색하여 웹서버로 전달하여 주고 통신을 연결해 준다

7. 크롬(Chrome) 브라우저 에러 유형

• Chrome 브라우저를 사용하다 보면 웹페이지를 제공하는 서버와 Chrome 브라우저가 소통하는 단계, 또는 기기와 네트워크의 연결, Chrome 브라우저가 해석할 수 없는 데이터를 전송받은 경우 에러가 발생한다
• 에러 메시지를 만나면, 다음과 같은 문제가 발생할 수 있다

     - 웹페이지에 연결할 수 없습니다.

     - 웹페이지가 열리지 않습니다.

     - HTTPS가 적용된 웹페이지가 열리지 않습니다.

     - 사진이 로드되지 않습니다.

     - 새 탭이 로드되지 않습니다.

• 전체 에러 메시지 확인 주소 :  chrome://network-errors/ 
• 크롬 고객센터 : https://support.google.com/chrome#topic=9796470

8. Chrome Network Tap 활용 방법

https://www.youtube.com/watch?v=e1gAyQuIFQo&t=482s 

※ 참조

https://en.wikipedia.org/wiki/IPv6

1. 클라이언트(Client) - 서버 아키텍쳐(Server Architecture)

• 클라이언트 : 리소스를 사용하는 주체를 의미한다
• 서버 : 리소스를 전달해 주는 역활을 한다
• 데이터베이스 : 리소스를 저장하는 공간이다

※ 아키텍쳐(Architecture) : 컴퓨터 시스템의 구성을 의미한다

 1) 2-Tier 아키텍쳐

• 클라이언트와 서버를 분리하여 리소스를 사용하는 방법이다
• 클라이언트가 요청 후 서버가 리소스를 제공한다

 2) 3-Tier 아키텍쳐

• 클라이언트 - 서버 - 데이터베이스 로 분리하여 리소스를 운영하는 방법이다

※  클라이언트 영역의 개발을 프론트엔드라고 한다

※  서버와 데이터베이스 영역의 개발을 백엔드라고 한다

※  데이터 동기화와 같은 서버와 서버 간의 통신을  inter-server commucation 이라고 한다

2. 클라이언트 - 서버 통신

 1) 프로토콜(Protocol)

• 통신 시스템이 데이터를 교환하기 위해 사용하는 컴퓨터 간 통신의 규약이다
• 클라이언트와 서버는 HTTP라는 프로토콜을 이용하여 정보를 주고 받는다
• 호스트의 계층 사이에는 인터페이스(Interface)라는 규칙이 존재한다
• 하위 계층이 상위 계층에 제공하는 인터페이스를 서비스(Service)라고 한다

• 호스트의 계층 사이에는 인터페이스(Interface)라는 규칙이 존재한다
• 하위 계층이 상위 계층에 제공하는 인터페이스를 서비스(Service)라고 한다
  
  더보기

  ▶ OSI 7 Layer 계층별 기능
  
   - 응용 계층(Application Layer)
    ▷ 사용자의 다양한 네트워크 응용 환경을 지원한다
    ▷ 한정된 범위가 아닌 광범위 환경을 지원한다
  
    - 표현 계층(Presentation Layer)
    ▷ 전송되는 데이터의 의미(Semantic)를 올바르게 표현하는 방법(Sintax)을 제공한다
    ▷ 정보를 교환하는 시스템이 표준화된 방법으로 데이터를 인식할 수 있도록 한다
    ▷ 주요 기능은 압축(Compression)과 암호화(Encrypt)가 있다
      → 압축은 데이터의 양을 줄여 준다
      → 암호화는 외부의 침입에서 데이터를 보호한다
  
    - 세션 계층(Session Layer0
    ▷ 전송계층과 유사하지만 더 상위의 논리적 연결이다
    ▷ 응용 환경에서의 사용자 간의 대화(Dialog) 개념의 연결로 사용된다 
   
  - 전송 계층(Transport Layer)
    ▷ 송신 프로세스와 수신 프로세스 간의 연결(Connection) 기능을 제공한다
    ▷ 프로세스 간의 안전한 데이터 전송을 지원한다
    ▷ 4 Layer까지의 기능은 운영체제에서 시스템 콜(Syatem Call) 형태로 상위 계층에 제공한다
    ▷ 5~7 Layer의 기능은 사용자 프로그램으로 작성되어 상위 계층에 제공한다 
      ※ 프로세스(Processs)
      → 일이 처리되는 과정이나 공정
      → 주어진 일을 해결하기 위한 목적으로 수행되는 순서가 정해져 있는 절차      
      → 컴퓨터에서 실행 중인 프로그램
  
   - 네트워크 계층(Network Layer)
    ▷ 송신 데이터가 수신 호스트까지 도착하는 과정에 올바른 경로를 선택하도록 지원한다
    ▷ 일반적으로 라우터(Router)가 수행한다
    ▷ 네트워크 부하가 증가하여 특정 지역에 혼잡(Congestion)이 발생할 경우에도 지원한다      
  
   - 데이터링크 계층(Data Link Layer)
    ▷ 물리 계층으로 데이터를 전송하는 과정에서 잡음과 같은 외부 요인에 의해 오류가 발생할 수 있다
    ▷ 물리적 전송 오류를 감지하는 기능을 제공하여 송수신 호스트가 오류를 인지할 수 있게 한다
    ▷ 컴퓨터 네트워크에서 오류가 발생할 경우 원 데이터를 재전송(Retransmission)하는 방법으로 오류 제어(Error Control)를 한다 
      ※ 물리적 오류 종류
      → 데이터가 도착하지 못하는 데이터 분실의 물리적 오류
      → 데이터 내용이 깨져서 도착하는 데이터 분실의 물리적 오류
  
   - 물리 계층 (Physical Layer)
    ▷ 네트워크에서 호스트가 데이터를 정송하기 위해서는 반드시 전송 매체로 연결되어 있어야 한다
    ▷ 호스트를 전송 매체와 연결하기 위한 인터페이스 규칙과 전송 매체의 특성을 제공한다

 2) API(Application Programming Interface)

• 클라이언트가 데이터에 편리하게 접근수 있도록 서버에서 정의한 규칙이다
• 클라이언트 - 서버 - 데이터베이스를 연결해 주는 역활을 한다
• 프로그램 내에서 실행을 위하여 특정 서브루틴에 연결을 제공하는 함수를 호출한다
• 한 개의 API는 함수의 호출에 의해 요청되는 작업을 수행하기 위하여 연결되어야 하는 프로그램 모듈을 가지고 있다