TIL 36. REST API 이해하기

문승준·2021년 10월 10일

API REST TIL restful api

Internet & Network

목록 보기

5/6

1. API

API는 프로그램들이 서로 상호작용하는 것을 도와주는 매개체이다.
API는 어떤 서버의 특정한 부분에 접속해서 그 안에 있는 데이터와 서비스를 이용할 수 있게 해주는 소프트웨어 도구이다.
API를 이용하면 두 개의 소프트웨어가 서로 통신을 주고받을 수 있으며, 이는 우리가 모바일을 이용해서 하는 모든 행동들의 기반을 이루고 있다.
API가 있음으로써 IT 아키텍처가 간단하게 만들어질 수 있고, 마케팅에 힘을 실어주며, 데이터 공유를 더 쉽게 해준다.

1-1. API 역할

1. API는 서버와 데이터베이스에 대한 출입구 역할을 한다.

데이터베이스에는 다양한 정보가 저장되는데 모든 사람들이 이 데이터베이스에 접근할 수 있으면 안된다.
API는 이를 방지하기 위해 우리가 가진 서버와 데이터베이스에 대한 출입구 역할을 하며, 허용된 사람들에게만 접근성을 부여해준다.

2. API는 애플리케이션과 기기가 원활하게 통신할 수 있도록 한다.

애플리케이션이란 우리가 흔히 알고 있는 스마트폰 어플이나 프로그램을 말한다.
API는 애플리케이션과 기기가 데이터를 원활히 주고받을 수 있도록 돕는 역할을 한다.

3. API는 모든 접속을 표준화한다.

API는 모든 접속을 표준화하기 때문에 기계/ 운영체제 등과 상관없이 누구나 동일한 액세스를 얻을 수 있다.
쉽게 말해, API는 범용 플러그처럼 작동한다.

1-2. API 유형

private API

private API는 내부 API로, 회사 개발자가 자체 제품과 서비스를 개선하기 위해 내부적으로 발행한다. 따라서 제 3자에게 노출되지 않는다.
public API
public API는 개방형 API로, 모두에게 공개된다. 누구나 제한 없이 API를 사용할 수 있는 게 특징이다.
partner API

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

1-3. API를 사용하는 이유

Private API를 이용할 경우, 개발자들이 애플리케이션 코드를 작성하는 방법을 표준화함으로써, 간소화되고 빠른 프로세스 처리를 가능하게 한다. 또한, 소프트 웨어를 통합하고자 할 때는 개발자들 간의 협업을 용이하게 만들어줄 수 있다.
public API와 partner API 를 사용하면, 기업은 타사 데이터를 활용하여 브랜드 인지도를 높일 수 있다. 뿐만 아니라 고객 데이터베이스를 확장하여 전환율까지 높일 수 있다.

2. REST API vs SOAP API

REST API

REST(Representational State Transfer)는 네트워크를 통해서 컴퓨터들끼리 통신할 수 있게 해주는 아키텍처 스타일이다.
REST API는 인터넷 식별자(URI)와 HTTP 프로토콜을 기반으로 한다. REST는 HTTP 프로토콜 덕분에 ‘단순함’이 핵심이라고 할 수 있으며, 데이터 포맷으로는 브라우저 간 호환성이 좋은 제이슨(JSON)을 사용한다.
REST API는 단일한 인터페이스를 사용하기 때문에 해당 API를 사용하는 애플리케이션들이 동일한 경로를 통해서 접속해야 하고, 그 방식이 단순하게 된다.
REST는 웹에 최적화되어 있고, 데이터 포맷이 JSON이기 때문에 브라우저들 간에 호환성이 좋다. 또한, 그 성능과 확장성이 뛰어난 것으로도 알려져 있다.

다른 기술들과 마찬가지로 그 자체의 기능이 정지되거나 앱을 먹통으로 만들 수도 있다. 그래서 REST로는 풀지 못하는 문제들을 해결하기 위해서 graphQL과 같은 언어가 생겨난 것이다.

SOAP API

SOAP(Simple Object Access Protocol)는 그 자체로 프로토콜이며, 보안이나 메시지 전송 등에 있어서 REST보다 더 많은 표준들이 정해져있기 때문에 조금 더 복잡하다.
오버헤드(처리시간과 메모리)가 많기는 하지만, 보안, 트랜잭션, ACID(원자성, 일관성, 고립성, 지속성)을 준수해야 하는 보다 종합적인 기능이 필요한 조직에게는 적합한 방식이다.
→ 웹서비스보다는 기업용 애플리케이션에 적합하다.

은행용 모바일 앱처럼 보안 수준이 높아야 하거나, 신뢰할 수 있는 메시징 앱, 또는 ACID를 준수해야 하는 경우라면 SOAP 방식이 더욱 선호된다.
SOAP 표준에는 성공/반복 실행 로직이 규정되어 있기 때문에, SOAP API를 통해서 통신을 할 때 처음부터 끝까지 신뢰성을 제공한다.
ACID를 준수하기 때문에 데이터의 변형을 줄여주고, 데이터베이스와의 상호작용에 대해서 사전에 정확하게 정하기 때문에 데이터의 무결성을 지켜준다.

참고 : SOAP REST 차이, 두 방식의 가장 큰 차이점은?

3. REST API

API 시스템 구현을 위한 아키텍처 중 가장 널리 사용되는 형식이다.
REST 외에도 Graphql, SOAP, GRPC 등이 있다.
리소스를 URI로 표현하고, 그 리소스에 대한 행위를 HTTP Method + Payload 로 정의한다. → 구조적으로 깔끔한 표현이 가능하다.

REST 구성과 특징

자원(Resorce) - URI
행위(Verb) - HTTP Method
표현(Representations)

1) Uniform (유니폼 인터페이스)

Uniform Interface는 URI로 지정한 리소스에 대한 조작을 통일되고 한정적인 인터페이스로 수행하는 아키텍처 스타일을 말한다.

2) Stateless (무상태성)

세션 정보나 쿠키정보를 별도로 저장하고 관리하지 않기 때문에 API 서버는 들어오는 요청만을 단순히 처리하면 된다. 때문에 서비스의 자유도가 높아지고 서버에서 불필요한 정보를 관리하지 않음으로써 구현이 단순해진다.

3) Cacheable (캐시 가능)

HTTP가 가진 캐싱 기능이 적용 가능하다. HTTP 프로토콜 표준에서 사용하는 Last-Modified태그나 E-Tag를 이용하면 캐싱 구현이 가능하다.

4) Self-descriptiveness (자체 표현 구조)

REST의 또 다른 큰 특징 중 하나는 REST API 메시지만 보고도 이를 쉽게 이해 할 수 있는 자체 표현 구조로 되어 있다는 것이다.

5) Client - Server 구조

REST 서버는 API 제공, 클라이언트는 사용자 인증이나 컨텍스트(세션, 로그인 정보)등을 직접 관리하는 구조로 각각의 역할이 확실히 구분되기 때문에 클라이언트와 서버에서 개발해야 할 내용이 명확해지고 서로간 의존성이 줄어들게 된다.

6) 계층형 구조

REST 서버는 다중 계층으로 구성될 수 있으며 보안, 로드 밸런싱, 암호화 계층을 추가해 구조상의 유연성을 둘 수 있고 PROXY, 게이트웨이 같은 네트워크 기반의 중간매체를 사용할 수 있게 한다.

쉽게말해, 다른 Tool이 필요없다. 진입장벽이 낮다. 러닝커브가 작다. 메시지 포맷이 짧아서 효율적이다. 프로세싱이 덜 소모되어 더 빠른 통신이 가능하다!

장점 : Self-descriptiveness 특성으로 RESTful API 그 자체만으로 API의 목적이 쉽게 이해된다.

단점 : 표준규약이 없어 안티패턴으로 작성되는 경우가 흔하다. (비효율, 비생산적인 패턴)

REST API 디자인 가이드

1. URI 정보를 명확하게 표현한다 → 명사형을 사용한다.

2. Resource에 대한 행위를 HTTP Method(GET, POST, PUT, DELETE)로 표현한다.

URI에 HTTP Method가 포함되면 안된다.
URI에 동사가 포함되면 안된다.
Resource 사이에 연관 관계가 있는 경우
- / 리소스 / 고유ID / 관계있는 리소스
- / users / {user_id} / profile
  → {}는 프론트 입장에서는 상수값이지만 백엔드는 변수로 사용한다.
파일 확장자를 URI에 포함시키지 않는다.
- GET / user / 1 / profile-photo
  → .jpg 확장자를 넣지 않고 headers의 content-type을 사용한다.
URI는 / 구분자를 통해 자원의 계층 관계를 나타낸다.
URI는 마지막 문자로 / 를 포함하지 않는다 → Query parameter 사용을 위해서
URI가 길어지면 - 을 사용하고 _ 는 안된다. (띄어쓰기 할때)
URI는 대문자 사용을 피한다.

응답상태코드 recap
1xx : 전송 프로토콜 수준의 정보 교환
2xx : 클라어인트 요청이 성공적으로 수행됨
3xx : 클라이언트는 요청을 완료하기 위해 추가적인 행동을 취해야 함
4xx : 클라이언트의 잘못된 요청
5xx : 서버쪽 오류로 인한 상태코드

‘REST API’를 제공하는 웹 서비스를 ‘RESTful’하다고 할 수 있다.
RESTful은 REST를 REST답게 쓰기 위한 방법으로, 누군가가 공식적으로 발표한 것이 아니다.
즉, REST 원리를 따르는 시스템은 RESTful이란 용어로 지칭된다.

RESTful한 API를 구현하는 근본적인 목적이 성능 향상에 있는 것이 아니라 일관적인 컨벤션을 통한 API의 이해도 및 호환성을 높이는 것이 주 목적이니, 성능이 중요한 상황에서는 굳이 RESTful한 API를 구현할 필요는 없다.