API, REST, REST API

'혼자 공부하는 얄팍한 코딩 지식'을 읽으며 추가적으로 공부한 내용을 정리한 글입니다.

---

1. API란?

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

군대에서 사용하는 수신호, 자동차의 방향지시등 같이 일상에서도 약속된 규칙과 신호로 소통을 하는 경우가 많이 있다.

상당수의 소프트웨어에서도 약속된 신호로 소통을 진행하는 경우가 많으며 이때 사용되는 것이 API이다.

 

이때 프로그램마다 API 설계 방식이 다르면 개발자들은 새로운 서비스를 만들 때마다 새로운 API를 고안하거나 기존 API를 읽히는 데 어려움을 겪을 것이다.

그래서 보편적으로 공유되는 방식인 REST API를 사용함으로써 보다 수월하게 개발을 진행할 수 있다.

 

API는 다수의 타 주체에게 특정 기능을 개방할 때도 사용된다.(public API)

예를 들어 공공 데이터 포털 사이트에서는 날씨, 행정, 법률 등 다양한 종류의 데이터 사용법과 함께 API를 제공하고 있다.

네이버나 다음, 구글의 지도 기능을 사용할 수 있는 것도 이들이 유료 혹은 무료 API로 공개했기 때문이다.

즉 API 사용법에 맞게 요청을 보내어 원하는 기능을 사용할 수 있다.

 

2. API 종류

 

(1) private API
private API는 내부 API로, 회사 개발자가 자체 제품과 서비스를 개선하기 위해 내부적으로 발행된다.

따라서 제 3자에게 노출되지 않는다.

 

(2) public API
public API는 개방형 API로, 모두에게 공개된다.

누구나 제한 없이 API를 사용할 수 있다.

 

(3) partner API
partner API는 기업이 데이터 공유에 동의하는 특정인들만 사용할 수 있다.

비즈니스 관계에서 사용되는 편이며, 종종 파트너 회사 간에 소프트웨어를 통합하기 위해 사용된다.

 

3. REST란?

REST API란 REST를 기반으로 만들어진 API를 의미한다.

 

그 중 REST의 의미를 먼저 파악하면

REST는 Representational State Transfer의 약어로 소프트웨어 아키텍처의 한 형식이고, 네트워크 아키텍처 원리의 모음이라고 정의한다.

그냥 쉽게 말하면 HTTP 통신을 잘 이용하기 위한 스타일의 하나로 볼 수 있다.

 

REST는 다음과 같은 3가지로 구성이 되어있다.

자원(Resource) : HTTP URI

자원에 대한 행위(Verb) : HTTP Method

자원에 대한 행위의 내용 (Representations) : HTTP Message Pay Load

 

REST는 HTTP 통신에서 특정 자원에 대한 요청을 받으면, 이를 URI와  HTTP 메서드를 사용해서 Resource(자원)와 Method(행위)로 표현하여 특정한 형태로 응답하는 것을 말한다.

(URL로 어떤 자원에 접근할 것인지, 메서드로 어떤 행위를 할 것인지 표현)

이외의 다른 아키텍처는 대표적으로 SOA가 있다.

 

즉 REST란

1. HTTP URI(Uniform Resource Identifier)를 통해 자원(Resource)을 명시하고,

2. HTTP Method(POST, GET, PUT, DELETE)를 통해 해당 자원(URI)에 대한 CRUD Operation을 적용하는 것을 의미한다.

 

CRUD Operation는 기본적인 데이터 처리 기능을 일컫는 말로 아래를 의미한다.

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

 

그리고 이런 REST의 원칙을 지키면서 API의 의미를 표현하고 쉽고, 파악하기 쉽게 하는 것을 Restful이라고 한다.

단 Restful이 되기 위한 조건이 있다.

(참고로 알아두면 좋다.)

 

Restful의 조건

1. Server-Client(서버-클라이언트 구조)

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

 

2. Stateless (무상태성)

REST는 무상태성 성격을 가진다.

즉 작업을 위한 상태정보를 따로 저장하고 관리하지 않는다.

세션 정보나 쿠키 정보를 별도로 저장하고 관리하지 않기 때문에 API 서버는 들어오는 요청만을 단순히 처리하면 된다.

그래서 서비스의 자유도가 높아지고 서버에서 불필요한 정보를 관리하지 않음으로써 구현이 단순해진다.

 

HTTP 통신의 특성 참고

쿠키, 세션, 토큰, 캐시

3. Cacheable(캐시 처리 가능)

캐시: 서버에서 한번 얻은 리소스를 재사용하여 클라이언트와 서버 간의 통신빈도를 줄인다.

네트워크 대역폭을 소비하고 서버로부터의 응답속도를 높일 수 있습니다. 단, 한 번 얻은 캐시의 정보가 오래되었거나, 정보의 신뢰성이 떨어지는 단점도 있기 때문에 사용 시 주의해야 한다.

 

4. Layered System(계층화)

클라이언트가 요청한 데이터를 검색하는 데 있어 필요한 관련된 서버의 각 유형을 클라이언트가 볼 수 없는 계층 구조로 체계화된 시스템이어야 한다.

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

 

5. Uniform Interface(인터페이스 일관성)

HTTP 표준에만 따른다면, 안드로이드/IOS 플랫폼이든, 특정 언어나 기술에 종속되지 않고 모든 플랫폼에 사용할 수 있으며, URI로 지정한 리소스에 대한 조작이 가능한 아키텍처 스타일을 의미한다.

 

REST의 장단점

 

장점

1. HTTP 프로토콜의 인프라를 그대로 사용하므로 REST API 사용을 위한 별도의 인프라를 구출할 필요가 없다.

2. HTTP 프로토콜의 표준을 최대한 활용하여 여러 추가적인 장점을 함께 가져갈 수 있게 해 준다. (1개의 URI로 4개의 행위(CRUD)를 명시할 수 있기 때문에 효율적이다.)

3. HTTP 표준 프로토콜에 따르는 모든 플랫폼에서 사용이 가능하다. (모두 같은 표준이니까)

4. Hypermedia API의 기본을 충실히 지키면서 범용성을 보장한다.

5. REST API 메시지가 의도하는 바를 명확하게 나타내므로 의도하는 바를 쉽게 파악할 수 있다. (URL만 보고 어떤 자원에 접근할 것인지, 메소드를 보고 어떤 행위를 할지 알 수 있기 때문에 보기 쉽다.)

6. 여러 가지 서비스 디자인에서 생길 수 있는 문제를 최소화한다.

7. 서버와 클라이언트의 역할을 명확하게 분리한다. (Server-Client(서버-클라이언트 구조) 특징은 Client 쪽에서는 Server 쪽에 신경 쓸 필요 없이 API 호출만 하면 원하는 결과를 받을 수 있다는 점을 의미)

 

단점

1. 표준이 자체가 존재하지 않아 정의가 필요하다.

2. 사용할 수 있는 메소드가 4가지밖에 없다.(POST, GET, PUT, DELETE)

3. HTTP Method 형태가 제한적이다.

4. 브라우저를 통해 테스트할 일이 많은 서비스라면 쉽게 고칠 수 있는 URL보다 Header 정보의 값을 처리해야 하므로 전문성이 요구된다.

5. 구형 브라우저에서 호환이 되지 않아 지원해주지 못하는 동작이 많다.(익스폴로어)

 

Rest API는 위에 말했듯이 REST의 원리를 따르는 API를 의미한다.

이런 REST API를 올바르게 설계하기 위해서는 몇 가지 규칙이 있다.

 

REST API 설계 규칙

 

1. URI는 동사보다는 명사를, 대문자보다는 소문자를 사용하여야 한다.

Bad Example http://khj93.com/Running/

Good Example http://khj93.com/run/

 

2. 마지막에 슬래시 (/)를 포함하지 않는다.

Bad Example http://khj93.com/test/

Good Example http://khj93.com/test

 

3. 언더바 대신 하이폰을 사용한다.

Bad Example http://khj93.com/test_blog

Good Example http://khj93.com/test-blog

 

4. 파일확장자는 URI에 포함하지 않는다.

Bad Example http://khj93.com/photo.jpg

Good Example http://khj93.com/photo

 

5. 행위를 포함하지 않는다.

Bad Example http://khj93.com/delete-post/1

 

이제 API를 사용해서 요청에 어떤 응답을 보낼지 정할 수 있게 되었다.

그러나 컴퓨터끼리 주고받는 정보가 간단할 때는 간단한 텍스트로 주고받을 수 있지만, 정보가 복잡해질 때는 다른 방법으로 주고받는 것이 좋다.

이때 사용하는 형식이 XML과 JSON이다.

이는 다음 포스트에 다루도록 하겠다.

 

참고했던 글들입니다.

[네트워크] REST API란? REST, RESTful이란?

[백엔드] Rest API / Restful API 란 무엇인가요

잘못된 내용이 있다면 지적부탁드립니다. 방문해주셔서 감사합니다.