API(Application Programming Interface)

vvinter·2024년 4월 3일
개발용어
0

개발용어

목록 보기
21/28

API 란?

API는 Application Programming Interface의 약자로, 소프트웨어 응용 프로그램에서 다른 소프트웨어 구성 요소 또는 서비스와 상호 작용하기 위한 인터페이스를 제공하는 프로그래밍 기술이다.

여기서 인터페이스는 두 소프트웨어 응용 프로그램 간의 서비스 계약이라고 할 수 있고, 이 계약은 ‘요청’과 ‘응답’을 사용하여 두 응용 프로그램이 서로 통신하는 방법을 정의한다.

쉽게 말하면, API는 두 소프트웨어의 구성 요소가 서로 통신할 수 있게 하는 메커니즘이라고 할 수 있다.

예를 들면, 기상청의 소프트웨어 시스템에는 일일 기상 데이터가 들어 있고, 휴대폰의 날씨 앱에서는 API를 통해 이 시스템과 통신하여 일일 날씨 정보를 표시해 주는 것이다.

📌  API 역할

  1. 서버와 데이터베이스에 대한 출입구 역할을 한다.
  2. 애플리케이션과 기기가 원활하게 통신할 수 있도록 한다.
  3. 모든 접속을 표준화한다.

📌  API 종류

✏️ 아키텍처 스타일에 따른 분류

API는 생성된 시기와 이유에 따라 4가지 방식으로 작동

  • SOAP API

    • SOAP API는 단순 객체 접근 프로토콜을 사용하며, 클라이언트와 서버는 XML을 사용하여 메시지를 교환
    • 현재보다 과거에 더 많이 사용되었으며 유연성이 떨어지는 API임.

  • RPC API

    • RPC API는 원격 프로시저 호출이라고도 하며, 클라이언트가 서버에서 함수나 프로시저를 완료하면 서버가 출력을 클라이언트로 다시 전송하는 형태

  • Websocket API

    • Websocket API는 JSON 객체를 사용하여 데이터를 전달하는 또 다른 최신 API, 구독형 API라고도 할 수 있음.
    • 클라이언트와 서버 간의 양방향 통신을 지원하며, 서버가 연결된 클라이언트에 콜백 메시지를 전송할 수 있어 REST API보다 효율적임.

  • REST API

    • 오늘날 웹에서 볼 수 있고 가장 많이 사용되고 있는 유연한 API
    • 클라이언트가 서버에 요청을 데이터로 전송하면 서버가 이 클라이언트 입력을 사용하여 내부 함수를 시작하고 출력 데이터를 다시 클라이언트에 반환함.

✏️ 접근 방식, 사용 범위에 따른 분류

  • 프라이빗 API

    • 프라이빗 API는 내부 API로, 기업 내부에 있으며 비즈니스 내에서 시스템과 데이터를 연결하는 데만 사용
    • 제3자에게 노출 X

  • 퍼블릭 API

    • 퍼블릭 API는 개방형 API로, 모두에게 공개되며 누구나 사용 가능
    • 누구나 제한 없이 API를 사용할 수 있지만, API와 관련된 권한 부여와 비용이 있을 수도 있고 없을 수도 있음.

  • 파트너 API

    • 기업이 데이터 공유에 동의하는 특정인들만 사용 가능
    • 주로 비즈니스 관계에서 사용되며, 종종 파트너 회사 간에 소프트웨어를 통합하기 위해 사용되기도 함.

  • 복합 API

    • 복합 API는 두 개 이상의 서로 다른 API를 결합하여 복잡한 시스템 요구 사항이나 동작을 처리

📌  API 장단점

✏️ 장점

  • 데이터 접속의 표준화와 편의성

    • 접근 방식에 따른 퍼블릭 API와 파트너 API 등의 종류들에서 알아봤듯이 API는 모든 접속을 표준화하기 때문에 디바이스/운영체제 등과 상관없이 조건만 맞다면, 누구나 동일한 액세스를 약속함.
    • 개발 시 API를 사용하면, 필요한 기본 기능들을 매번 개발/업데이트할 필요 없이 손쉽게 이용 가능

  • 자동화와 확장성

    • API를 통한 CRUD 처리에 따라 관련 데이터와 콘텐츠가 자동으로 생성되고 사용자의 환경에 맞춰서 정보가 전달되어 개발 워크플로우가 간소화되고 애플리케이션 확장이 용이
    • 예를 들면, API를 활용한 웹 사이트 분석, 프로젝트 및 팀 관리 도구, 온라인 결제 시스템, 기타 여러 운영 솔루션에 필요한 애플리케이션을 다소 쉽게 작성할 수 있음

  • 적용력

    • API는 변화 예측에도 큰 도움이 되기 때문에, API를 통해 데이터를 수집하고 전달하는 데 있어 유연한 서비스 환경을 구축하고 소프트웨어를 통합하거나 협업이 필요할 때 더욱 용이

✏️ 단점

  • 보안성과 HTTP 방식의 제한

    • API의 단일 진입점인 API 게이트웨이는 해커의 타겟 대상이 될 수 있음. 즉, 평범한 HTTP 메서드를 사용하여 액세스할 수 있다는 장점이, 보안성에 관해서는 크나큰 단점이 될 수 있음

  • 표준의 부재와 개발 비용

    • REST API의 설계에 있어 가장 큰 단점이라고 할 수 있는 공식화된 표준이 존재하지 않는다는 점임.
    • 따라서 관리가 어렵고, 실제 API 기능을 구현하고 제공하려면 개발 시간, 지속적인 유지 관리, 요구 사항 및 지원 제공 측면에서 비용이 많이 들 수 있음
    • 또한 기존 API의 기능을 확장하려고 할 때, 광범위한 프로그래밍 지식이 필요함

📌  API 엔드포인트

API 엔드포인트는 API 호출이 수행되는 곳을 뜻하며, 해당 API를 호출할 때의 URL이라고 이해하면 쉽다.

REST API 란?

REST API란 말 그대로 REST 형식의 API를 말하며, 핵심 컨텐츠 및 기능을 외부 사이트에서 활용할 수 있도록 제공되는 인터페이스이다.

📌  REST란?

REST란 Representational State Transfer의 약자로, 자원을 이름으로 구분하여 해당 자원의 상태를 주고받는 모든 것을 의미한다.

💡 즉, REST는
1. HTTP URI(Uniform Resource Identifier)를 통해 자원을 명시하고,
2. HTTP Method(POST, GET, PUT, DELETE, PATCH 등)를 통해
3. 해당 자원(URI)에 대한 CRUD Operation을 적용하는 것을 의미

++) CRUD Operation

: Create(생성), Read(읽기), Update(갱신), Delete(삭제)를 묶어서 일컫는 말로, REST에서의 CRUD Operation 동작 예시는 다음과 같다.

  • Create : 데이터 생성(POST)
  • Read : 데이터 조회(GET)
  • Update : 데이터 수정(PUT, PATCH)
  • Delete : 데이터 삭제(DELETE)

📌  REST의 구성 요소

자원(Resource), 행위(Verb), 표현(Representations)의 3가지 요소로 구성

  • 자원 (Resource)

    • 모든 자원에 고유한 ID가 존재하고, 이 자원은 서버에 존재
    • 자원을 구별하는 ID는 /orders/order_id/1 와 같은 HTTP URI

  • 행위 (Verb)

    • HTTP 프로토콜의 Method를 사용

  • 표현 (Representations)

    • 클라이언트가 자원의 상태에 대한 조작을 요청하면 서버는 이에 적절한 응답을 보냄
    • REST에서 하나의 자원은 JSON, XML, TEXT, RSS 등 여러 형태의 응답으로 나타낼 수 있으며, 현재는 JSON으로 주고받는 것이 대부분임

  • HTTP Method


📌  REST 특징

  • 클라이언트 / 서버 구조

    • 클라이언트는 유저와 관련된 처리를, 서버는 REST API를 제공함으로써 각각의 역할이 확실하게 구분되고, 일괄적인 인터페이스로 분리되어 작동할 수 있게 함
      ⇒ 서로 간 의존성이 줄어듦

  • 무상태성

    • HTTP의 특성을 이용하기 때문에 무상태성을 가짐
    • 즉, 서버에서 어떤 작업을 하기 위해 상태정보를 기억할 필요가 없고 들어온 요청에 대해 처리만 해주면 되기 때문에 구현이 쉽고 단순

  • 캐시 처리 가능

    • HTTP라는 기존 웹 표준을 사용하는 REST의 특징 덕분에 기본 웹에서 사용하는 인프라를 그대로 사용할 수 있음
    • 대량의 요청을 효율적으로 처리하기 위해 캐시가 요구됨
      ⇒ 캐시 사용을 통해 응답시간이 ⬆️, REST Server 트랜잭션이 발생하지 않기 때문에 전체 응답시간, 성능, 서버의 자원 이용률을 향상 시킬 수 있음

  • 자체 표현 구조

    • JSON을 이용한 메시지 포맷을 이용하여 직관적으로 이해할 수 있음
    • REST API 메시지만으로도 그 요청이 어떤 행위를 하는지 확인 가능

  • 계층화

    • 클라이언트와 서버가 분리되어 있기 때문에 중간에 프록시 서버, 암호화 계층 등 중간매체를 사용할 수 있어 자유도가 높음

  • 유니폼 인터페이스

    • HTTP 표준에만 따른다면 모든 플랫폼에서 사용이 가능하며, URI로 지정한 리소스에 대한 조작을 가능하게 하는 아키텍처 스타일을 뜻함.
    • 특정 언어나 기술에 종속되지 않음

📌  REST API 설계

✓ REST 중심 규칙

  1. URI는 정보의 자원을 표현해야 한다.
    • 리소스명은 동사보다는 명사 사용.
    • URI는 자원을 표현하는 데 중점을 두어야 하며, get 같은 행위에 대한 표현이 들어가서는 안 됨.
  2. 자원에 대한 행위는 HTTP Method (GET, POST, PUT, DELETE 등)으로 표현한다.

✓ 세부 규칙

  1. 슬래시 구분자(/)는 계층 관계를 나타내는 데 사용
  2. URI 마지막 문자로 슬래시(/) 포함 x
  3. 하이픈(-)은 URI 가독성을 높이는 데 사용
  4. 밑줄(_)은 URI에 사용 x
  5. URI 경로에는 소문자가 적합
  6. 파일 확장자는 URI에 포함하지 x

📌  Collection, Document

  • Collection
    • 문서들의 집합, 객체들의 집합
  • Document
    • 단순히 문서로 이해해도 되고, 한 객체라고 이해해도 좋음

➡️ 컬렉션과 도큐먼트는 모두 자원(리소스)이라고 표현할 수 있으며, URI에 표현됨.

사용 예시)

http://restapi.example.com/sports/soccer
=> sports 컬렉션, soccer 도큐먼트로 표현

http://restapi.example.com/sports/soccer /player/13
=> sports, player 컬렉션, soccer, 13 도큐먼트로 표현
=> 컬렉션은 복수로 사용 중


📌  HTTP 응답 상태 코드

리소스에 대한 응답 확인하기

⇒ 정확한 응답의 상태코드만으로도 많은 정보를 전달할 수 있기 때문에 응답의 상태코드 값을 명확히 돌려주는 것은 중요!





📎  참고

https://aws.amazon.com/ko/what-is/api/
https://stdio-han.tistory.com/88
https://blog.wishket.com/api란-쉽게-설명-그린클라이언트/
https://www.cloudflare.com/ko-kr/learning/security/glossary/what-is-endpoint/
https://www.hanl.tech/blog/api란-api의-정의와-종류-장단점/
https://velog.io/@min-zi/Web-API-엔드포인트란
https://gapal.tistory.com/24
https://khj93.tistory.com/entry/네트워크-REST-API란-REST-RESTful이란
https://velog.io/@somday/RESTful-API-이란
https://poiemaweb.com/js-rest-api
https://inpa.tistory.com/entry/WEB-🌐-REST-API-정리#rest_구성

profile
vvinter
📎
이전 포스트

IDE(Integrated Development Environment)

다음 포스트

프로토콜(Protocol)

0개의 댓글