[CS] API(Application Programming Interface)란?

API 란?

 API(Application Programming Interface)는 둘 이상의 컴퓨터가 서로 통신하는 방법이자, 컴퓨터 사이의 중계 계층을 뜻합니다.

• Application : 특정 업무를 수행하기 위한 응용 소프트웨어
• Programming : 컴퓨터에 부여하는 명령을 만드는 작업
• Interface : 사물과 사물 사이 또는 사물과 인간 사이의 경계에서 서로 소통하기 위해 만들어진 매개체

종합하면 응용 소프트웨어를 통해 특정 작업을 수행하기 위해 필요한 데이터 전송 통신에서 컴퓨터(서버)와 사용자(클라이언트) 사이의 데이터 전송 통신을 위한 매개체라고 볼 수 있습니다. 조금 더 쉽게 말하자면, API는 프로그램들이 서로 상호작용하는 것을 도와주는 매개체로 볼 수 있습니다.

 

API의 역할

1. 클라이언트와 서버의 중간에서 서버와 클라이언트가 소통하기 위한 규칙을 정합니다.
2. API는 클라이언트로부터 전달 받은 요청을, 서버에 전달하여 처리하기에 앞서 받은 데이터를 서버가 처리하기 용이하게 맞추기도 하고, 전달받은 데이터를 서버에게 데이터를 요청하고, 다시 서버로부터 전달받은 데이터를 클라이언트에게 다시 전달해주는 중계자 역할을 합니다.

 

API의 장점

API를 사용하면 많은 이점들이 있습니다.

• API 제공자는 서비스의 중요한 부분을 드러내지 않아도 됩니다.
  • 서버 입장에서, 데이터베이스 구조나, 테이블 정보, 서버 내부에서 사용하는 정보들을 외부적으로 노출하지 않게 함으로써, 보안성을 높일 수 있습니다.
• 반대로 클라이언트 입장에서는 서버가 해당 서비스를 어떻게 제공하는지에 대한 코드나 서버 내부 정보를 알 필요 없이, 사용자가 필요로 하는 정보들을 받을 수 있습니다.

 

API의 종류

1. private API

• private API는 내부 API로, 외부에 노출되지 않은 API를 의미합니다. 클라이언트는 접근하지 못하도록 설정하게 하며, API 개발자가 자체 제품과 서비스를 개선하기 위해 내부적으로 만드는 API로 3자에게 노출되지 않습니다.

2. public API

• 일반적인 API를 의미하며, 모두에게 공개됩니다. 클라이언트가 제약, 제한 없이 접근할 수 있는 것이 특징이지만, 많은 트래픽을 방지하기 위해 계정 당 하루 요청수의 제한을 걸어놓기도 합니다.

3. parter API

• 기업이 데이터 공유에 동의하는 특정인들만 사용할 수 있도록 개발하는 API로, 비즈니스 관계에서 사용되는 편이며, 종종 파트너 회사간 소프트웨어 통합을 위해 만드는 API

 

REST API란? 

• A라는 개발자가 만든 API를 B라는 개발자는 이해하기 어려운 것처럼 API를 사용하다보니 개발자마다 소통의 규칙과 메뉴얼 등이 달라 겪는 문제가 발생할 수 있습니다. 따라서 API도 체계가 필요하다는 관점으로 나온 방법이 REST API로, API를 만들 때 지켜야 할 약속들을 개발자들끼리 규칙화 해놓은 API입니다.

* REST API에서 REST는 Representational State Transfer의 약자.

 

REST API - Request 

데이터를 불러올 때, HTTP URI로 어떤 자원을 통해 데이터를 얻을 것인지 표시해 주어야 하는데, 이 때 HTTP 메소드를 통해 해당 자원에 대한 행위를 규칙으로 정해놓았습니다. 

 

기본 규칙

• URI는 정보의 자원을 표현해야 한다
• 자원에 대한 행위는 HTTP Method (GET, POST, PUT, DELETE 등)으로 표현한다

메소드 종류

• GET : 읽어오기 ( ex) 웹 페이지에서 글을 읽어오는 요청 )
• POST : 쓰기 ( ex) 웹 페이지에 글을 작성하는 요청 )
• DELETE : 삭제 ( ex) 웹 페에지에서 글을 삭제하는 요청 )
• PUT / PATCH : 수정 ( ex) 웹 페이지에서 글을 수정하는 요청 )

 

REST API - Response 

행위에 대한 응답은 표현으로 JSON으로 주고받는 것이 대부분.

 

Restful 하기 위한 개발 원칙

Restful하다는 것은 REST API를 REST 답게 쓰기 위한 방법으로, 누군가 공식적으로 발표한 것은 아니지만 정해진 규칙이 있습니다.

 

1. 자원을 식별할 수 있어야 한다.

• URL(Uniform Resource Locator) 만으로 내가 어떤 자원을 제어하려고 하는지 알 수 있어야 합니다. 자원을 제어하기 위해서, 자원의 위치는 물론 자원의 종류까지 알 수 있어야 한다는 의미
• Server가 제공하는 정보는 JSON 이나 XML 형태로 HTTP body에 포함하여 전송.

2. 행위는 명시적이어야 한다.

• REST는 아키텍쳐 혹은 방법론과 비슷합니다. 따라서 이런 방식을 사용해야 한다고 강제적이지는 않습니다만 (GET을 이용해서 UPDATE와 DELETE를 해도 되긴 함) 행위(메소드)를 명시적으로 사용해야 Restful하다고 할 수 있습니다.

3. 자기 서술적이어야 한다.

• 데이터에 대한 메타정보만 가지고도 어떤 종류의 데이터인지, 데이터를 위해서 어떤 어플리케이션을 실행 해야 하는지를 알 수 있어야 합니다.
• 즉, w데이터 처리를 위한 정보를 얻기 위해서, 데이터 원본을 읽어야 한다면 자기 서술적이지 못하다

4. HATEOS (Hypermedia as the Engine of Application State)

• 클라이언트 요청에 대해 응답을 할 때, 추가적인 정보를 제공하는 링크를 포함할 수 있어야 한다.
• REST는 독립적으로 컴포넌트들을 손쉽게 연결하기 위한 목적으로도 사용된다. 따라서 서로 다른 컴포넌트들을 유연하게 연결하기 위해선, 느슨한 연결을 만들어줄 것이 필요하다.
• 이때 사용되는 것이 바로 링크이다. 서버는 클라이언트 응용 애플리케이션에 하이퍼 링크를 제공한다.
• 클라이언트는 이 하이퍼 링크를 통해서 전체 네트워크와 연결되며 HATEOAS는 서버가 독립적으로 진화할 수 있도록 서버와 서버, 서버와 클라이언트를 분리 할 수 있게 한다.

 

RestAPI의 단점

1. REST는 point-to-point 통신모델을 기본으로 하기 때문에, 서버와 클라이언트가 연결을 맺고 상호작용 해야하는 어플리케이션의 개발에는 적당하지 않습니다.
2. REST는 URI, HTTP 이용한 아키텍처링 방법에 대한 내용만을 담고 있고, 보안과 통신규약 정책 같은 것은 전혀 다루지 않기 때문에 따라서 개발자는 통신과 정책에 대한 설계와 구현을 도맡아서 진행해야 합니다.

 

 

참고 자료 

API란? 비개발자가 알기 쉽게 설명해드립니다! - wishket