📍 들어가며

공부를 시작하며 깊게 알수록 자주 등장하는 단어 , API, REST, REST API 등 자주 보이고 공부하며 사용하는데 정확히 무엇인지 설명하기가 어렵고 왜 사용하는지 정확한 이유도 모르고 사용하고 있었던것 같다. 이 글을 정리하며 정확히 무엇이고, 왜 사용하는지 정리해보고자 한다.


📍 API (Application Programming Interface)

API는 응용 프로그램에서 사용할 수 있도록 운영체제나
프로그래밍 언어가 제공하는 기능을 제어할 수 있게 만든 인터페이스를 뜻한다.

API는 여러 프로그램들과 데이터베이스, 그리고 기능들의 상호 통신 방법을 규정하고 도와주는 매개체이다.

예를 들어 API는 식당의 점원이다. 손님은 점원에게 음식을 주문하고, 점원은 주문을 요리사에게 전달한다. 요리사는 요리를 만들어 점원에게 주고 점원은 손님이게 요리를 서빙한다.
이처럼 API는 식당의 점원과 같은 역할을 한다. 여기서 손님과 요리사는 프로그램으로 비유한다.
즉 API는 프로그램들이 서로 상호 작용하는 것을 도와주는 매개체라고 할 수 있다.

API의 종류

1. Private API

회사 개발자가 자체 제품과 서비스를 개선하기 위해 내부적으로 발행하는 API, 제 3자에게 노출되지 않는다.

2. Publick API

누구나 제한없이 API를 사용할 수 있는 개방형 API, Publick API 중에서도 접속하는 대상에 대한 제약이 없는 경우를 OpenAPI라고 한다.

OpenAPI 사이트

3. Partner API

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


📍 REST (Representational State Transfer)

단순하고 가벼운 웹(HTTP)의 우수성에 비해 제대로 사용되지 못하는 것을 안타까워 웹의 장점을 최대한 활용할 수 있는 아키텍처로 REST발표, 화려하지만 무겁고 복잡한 통신보다는 이미 만들어져있는 HTTP 프로토콜의 고유한 기능을 통해 가볍고 단순한 빠른 통신을 하자는 취지

  • REST는 HTTP를 기반으로 필요한 자원에 접근하는 방식을 정해놓은 아키텍처라고 할 수 있다. 여기서 자원이란 소프트웨어가 관리하는 모든 것(문서,그림,데이터 등)을 의미한다.

  • REST는 월드 와이드 웹(WWW)과 같은 분산 하이퍼 미디어 시스템을 위한 소프트웨어 개발 아키텍처의 한 형식이다.

  • REST는 웹의 기존 기술과 HTTP프로토콜을 그래도 활용하기 때문에 웹의 장점을 최대한 활용할 수 있다.

REST의 구성

자원 (Resource) - URL

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

행위 (Verb) - HTTP Method

  • HTTP 프로토콜의 Method를 사용한다.
  • HTTP 프로토콜은 GET, POST, PUT, DELETE와 같은 메서드를 제공한다.

표현 (Representation of Resource)

  • Client가 자원의 상태(정보)에 대한 조작을 요청하면 Server는 이에 적절한 응답을 보낸다.
  • REST에서 하나의 자원은 JSON, XML, TEXT, RSS 등 여러 형태의 Representation으로 나타낼 수 있다.
  • 현재는 JSON으로 주고 받는 것이 대부분이다.

REST의 특징

  • Server-Client 구조

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

  • 무상태성 - Stateless

    HTTP 프로토콜은 Stateless protocol 이므로 REST 역시 무상태성을 갖는다. Client의 context를 Server에 저장하지 않는다. Server는 각각의 요청을 완전히 별개의 것으로 인식하고 처리한다.

  • 캐시 처리 가능 - Cacheable

    HTTP의 특징인 캐싱 기능을 적용할 수 있다. 캐시 사용을 통해 응답 시간이 빨라진다.

  • 계층화 - Layered System

    Client는 REST API Server만 호출하고, REST Server는 다중 계층으로 구성될 수 있다.

  • 유니폼 인터페이스 - Uniform Interface

    URI로 지정한 Resource에 대한 조작을 통일되고 한정적인 인터페이스로 수행한다. 즉 특정 언어나 기술에 종속되지 않는다.

  • 자체 표현 구조 - Self-descriptiveness

    REST API 메세지만 보고도 이를 쉽게 이해할 수 있는 자체 표현 구조로 되어있다.


REST 의 장단점

장점

  • HTTP 프로토콜의 인프라를 그대로 사용하므로 REST API 사용을 위한 별도의 인프라를 구축할 필요가 없다.
  • HTTP 프로토콜의 표준을 최대한 활용하여 여러 추가적인 장점을 함께 가져갈 수 있게 해준다.
  • HTTP 표준 프로토콜에 따르는 모든 플랫폼에서 사용이 가능하다.
  • Hypermedia API의 기본을 충실히 지키면서 범용성을 보장한다.
  • REST API 메세지가 의도하는 바를 명확하게 나타내므로 의도하는 바를 쉽게 파악할 수 있다.
  • 서버와 클라이언트의 역할을 명확하게 분리한다.

단점

  • 표준이 존재하지 않는다.
  • 사용할 수 있는 메서드가 4가지 밖에 없다. (HTTP Method 형태가 제한적이다.)

📍 REST API

REST API는 REST 기반으로 서비스 API를 구현한 것이다.
최근 OpenAPI, 마이크로 서비스 등을 제공하는 업체 대부분은 REST API를 제공한다.

REST API와 다른 API의 차이점은 API를 실행하는 컴퓨터(클라이언트)에서 기능을 처리하는게 아닌 HTTP 프로토콜의 URI 주소를 이용해 서버의 기능을 처리하게 하는 것이다.

REST API에서 처리할 수 있는 기능을 메서드라고 하는데 REST는 Web의 통신 규약인 HTTP 프로토콜을 이용하기 때문에 HTTP에 존재하는 메소드를 그대로 사용한다.

HTTP VerbREST API METHOD (CRUD)설명
POSTCreate생성하기
GETRead읽기
PUTUpdate전체 변경하기
PATCHUpdate부분 변경하기
DELETEDelete삭제하기

📍 RESTful ??

Restful 하다는 것은 REST의 원리를 따르는 시스템을 의미한다. 하지만 REST를 사용했다 해서 모두가 RESTful 한 것은 아니다. REST API의 설계 규칙을 올바르게 지킨 시스템을 RESTful하다 말할 수 있으며, 모든 CRUD 기능을 POST로 처리하는 API 혹은 URI 규칙을 올바르게 지키지 않은 API는 REST API의 설계 규칙을 올바르게 지키지 못한 시스템이고 이런 경우 REST API를 사용했지만 RESTful 하지 못한 시스템이라 말할 수 있다.


📍 참고 사이트

  1. https://www.hanl.tech/blog/api%EB%9E%80-api%EC%9D%98-%EC%A0%95%EC%9D%98%EC%99%80-%EC%A2%85%EB%A5%98-%EC%9E%A5%EB%8B%A8%EC%A0%90/
  2. https://code-lab1.tistory.com/194
  3. https://aws.amazon.com/ko/what-is/restful-api/
  4. https://sidepower.tistory.com/408
profile
프론트엔드 개발자가 되겠습니다🔥

0개의 댓글