[CS] REST API

REST API란 무엇인가?

REST는 Representational State Transfer의 줄임말이다. (직역 : 대행 상태 전송)

REST는 클라이언트가 서버 데이터에 액세스하는 데 사용할 수 있는 GET, POST, PUT, DELETE 등의 함수 집합을 정의.

클라이언트와 서버는 HTTP를 사용하여 데이터를 교환한다.

 

REST API의 주된 특징은 무상태다. 무상태는 서버가 요청 간에 클라이언트 데이터를 저장하지 않음을 의미한다.

서버에 대한 클라이언트 요청은 웹 사이트를 방문하기 위해 브라우저에 입력하는 URL과 유사하다.

서버의 응답은 웹 페이지의 일반적인 그래픽 렌더링이 없는 일반 데이터다.

REST 구성

쉽게 말해 REST API는 다음의 구성으로 이루어져있다. 자세한 내용은 밑에서 설명하도록 하겠다.

• 자원(RESOURCE) - URI
• 행위(Verb) - HTTP METHOD
• 표현(Representations)

REST API 디자인 가이드

REST API 설계 시 가장 중요한 항목은 다음의 2가지로 요약할 수 있다.

첫 번째, URI는 정보의 자원을 표현해야 한다. 두 번째, 자원에 대한 행위는 HTTP Method(GET, POST, PUT, DELETE)로 표현한다.

다른 것은 다 잊어도 위 내용은 꼭 기억해야 한다.

REST API 중심 규칙

1) URI는 정보의 자원을 표현해야 한다. (리소스명은 동사보다는 명사를 사용)

    GET /members/delete/1

위와 같은 방식은 REST를 제대로 적용하지 않은 URI다. URI는 자원을 표현하는데 중점을 두어야 한다. delete와 같은 행위에 대한 표현이 들어가서는 안 된다.

2) 자원에 대한 행위는 HTTP Method(GET, POST, PUT, DELETE 등)로 표현

위의 잘못 된 URI를 HTTP Method를 통해 수정해 보면

    DELETE /members/1

으로 수정할 수 있겠다. 회원정보를 가져올 때는 GET, 회원 추가 시의 행위를 표현하고자 할 때는 POST METHOD를 사용하여 표현한다.

회원정보를 가져오는 URI

    GET /members/show/1     (x)
    GET /members/1          (o)

회원을 추가할 때

    GET /members/insert/2 (x)  - GET 메서드는 리소스 생성에 맞지 않습니다.
    POST /members/2       (o)

[참고]

HTTP METHOD의 알맞은 역할

POST, GET, PUT, DELETE 이 4가지의 Method를 가지고 CRUD를 할 수 있다.

POST	POST를 통해 해당 URI를 요청하면 리소스를 생성한다.
GET	GET를 통해 해당 리소스를 조회합니다. 리소스를 조회하고 해당 도큐먼트에 대한 자세한 정보를 가져온다.
PUT	PUT를 통해 해당 리소스를 수정한다.
DELETE	DELETE를 통해 리소스를 삭제한다.

REST 의 특징

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

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

2) Stateless (무상태성)

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

3) Cacheable (캐시 가능)

REST의 가장 큰 특징 중 하나는 HTTP라는 기존 웹표준을 그대로 사용하기 때문에, 웹에서 사용하는 기존 인프라를 그대로 활용이 가능하다. 따라서 HTTP가 가진 캐싱 기능이 적용 가능하다. HTTP 프로토콜 표준에서 사용하는 Last-Modified태그나 E-Tag를 이용하면 캐싱 구현이 가능하다.

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

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

5) Client - Server 구조

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

6) 계층형 구조

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

REST API를 사용하면 어떤 이점이 있나?

REST API는 다음과 같은 네 가지 주요 이점을 제공한다.

1. 통합

API는 새로운 애플리케이션을 기존 소프트웨어 시스템과 통합하는 데 사용된다. 그러면 각 기능을 처음부터 작성할 필요가 없기 때문에 개발 속도가 빨라진다. API를 사용하여 기존 코드를 활용할 수 있다.

2. 혁신

새로운 앱의 등장으로 전체 산업이 바뀔 수 있다. 기업은 신속하게 대응하고 혁신적인 서비스의 신속한 배포를 지원해야 한다. 전체 코드를 다시 작성할 필요 없이 API 수준에서 변경하여 이를 수행할 수 있다.

3. 확장

API는 기업이 다양한 플랫폼에서 고객의 요구 사항을 충족할 수 있는 고유한 기회를 제공한다. 예를 들어 지도 API를 사용하면 웹 사이트, Android, iOS 등을 통해 지도 정보를 통합할 수 있다. 어느 기업이나 무료 또는 유료 API를 사용하여 내부 데이터베이스에 유사한 액세스 권한을 부여할 수 있다.

4. 유지 관리의 용이성

API는 두 시스템 간의 게이트웨이 역할을 한다. API가 영향을 받지 않도록 각 시스템은 내부적으로 변경해야 한다. 이렇게 하면 한 시스템의 향후 코드 변경이 다른 시스템에 영향을 미치지 않는다.

REST API를 보호하려면 어떻게 해야 하나?

모든 API는 적절한 인증 및 모니터링을 통해 보호되어야 한다. 다음은 REST API를 보호하는 두 가지 주요 방법이다.

1. 인증 토큰

인증 토큰은 사용자에게 API 호출을 수행할 수 있는 권한을 부여하는 데 사용된다. 인증 토큰은 사용자가 자신이 누구인지 확인하고 해당 특정 API 호출에 대한 액세스 권한이 있는지 확인한다. 예를 들어, 이메일 서버에 로그인하면 이메일 클라이언트는 보안 액세스를 위해 인증 토큰을 사용한다.

2. API 키

API 키는 API를 호출하는 프로그램 또는 애플리케이션을 확인한다. 즉, 애플리케이션을 식별하고 애플리케이션에 특정 API 호출을 수행하는 데 필요한 액세스 권한이 있는지 확인한다. API 키는 토큰만큼 안전하지 않지만 사용량에 대한 데이터를 수집하기 위해 API 모니터링을 허용한다. 다른 웹 사이트를 방문할 때 브라우저 URL에서 긴 문자열과 숫자를 본 적이 있을 것이다. 이 문자열은 웹 사이트가 내부 API 호출을 수행하는 데 사용하는 API 키다.