Web - REST API

REST

REST란?

REST는 Representational State Transfer의 줄임말이다. 자원을 이름으로 구분 짓고 해당 자원의 상태를 교환하는 것을 의미한다. 좀 더 구체적으로 설명하자면, HTTP URI를 통해 자원을 명시하고, HTTP Method를 통해 자원을 교환하는 것을 말한다. 이러한 REST는 서버와 클라이언트의 통신 방식 중 하나이다.

 

REST의 장단점

장점

ㆍ HTTP 프로토콜의 인프라를 그대로 사용하기 때문에, REST API 사용을 위한 별도의 인프라를 구축할 필요가 없다.

ㆍ HTTP 표준 프로토콜을 따르는 모든 플랫폼에서 사용이 가능하다.

ㆍ REST API 메시지가 의도하는 바를 명확하게 나타내기 때문에, 의도하는 바를 쉽게 파악할 수 있다.

ㆍ 서버와 클라이언트의 역할을 명확하게 분리하기 때문에, 서로에게 영향을 주지 않고 독립적으로 작업이 가능하다.

 

단점

ㆍ REST 자체에 대한 표준이 존재하지 않는다.

ㆍ 사용할 수 있는 메서드가 GET, POST, PUT, DELETE 4가지 밖에 없다.

ㆍ PUT, DELETE와 같이 구형 브라우저가 제대로 지원해주지 못하는 부분이 존재한다.

 

REST가 필요한 이유

최근의 서버 프로그램은 다양한 브라우저와 안드로이드폰, 아이폰과 같은 모바일 디바이스에서도 통신을 할 수 있어야 한다. 이러한 멀티 플랫폼에 대한 지원을 위해 자원에 대한 아키텍처를 세우고 이용하는 방법을 모색한 결과 REST에 관심을 가지게 되었다.

 

REST의 구성 요소

Resource(자원) : URI

ㆍ 모든 자원에는 고유한 ID가 존재하고, 이 자원은 서버에 존재한다.

ㆍ 자원을 구별하는 ID는 "/groups/:group_id"와 같은 HTTP URI이다.

ㆍ 클라이언트는 URI를 이용해서 자원을 지정하고, 해당 자원의 상태에 대한 조작을 서버에 요청한다.

 

행위(Verb) : HTTP Method

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

ㆍ HTTP Header를 통해 행위를 표현한다.

 

표현(Representation of Resource)

ㆍ 클라이언트가 자원의 상태에 대한 조작을 요청하면 서버는 이에 적절한 응답을 보낸다.

ㆍ REST에서 하나의 자원은 XML, JSON, TEXT 등 여러 형태로 나태낼 수 있다.

ㆍ JSON을 통해서 데이터를 주고받는 것이 일반적이다.

 

REST의 특징

1. Server-Client Architecture

서버와 클라이언트가 독립적으로 분리되어 있어야 한다. User Interface와 데이터를 저장하는 두 가지의 영역을 분리하게 되면, 서버가 처리할 부분이 줄어들고 확장하기가 쉬워진다. 요즘은 하나의 데이터를 여러 가지 기기에서 보여주어야 하기 때문에 REST API의 사용이 효율적이다.

 

2. Stateless

서버는 클라이언트에 대한 사전 정보나 클라이언트의 상태를 저장하지 않는다. 다르게 말하면, 서비스의 클라이언트가 동작하는 과정에서 생기는 상태 변화에 대해 서버는 전혀 관여하지 않음을 뜻한다. 그렇기 때문에 요청 시 서버가 해당 요청을 처리하기 위해 필요로 하는 모든 정보를 함께 전송해야 한다.

 

3. Cacheable

응답과 요청이 모두 캐싱 처리가 가능한지 아닌지 명시가 필요하다. 캐싱이 가능한 데이터라면 클라이언트 차원에서 캐시에 저장해 두고 이후에 같은 요청에 대해서 해당 데이터를 꺼내올 수 있다.

 

4. Layered System

서버는 보안을 위해서 여러 겹의 서버나 통신이 있을 수 있고, 프록시나 로드 밸런서와 연결되어 작동하는 등 다중 계층으로 구성될 수 있다. 하지만, 클라이언트 입장에서는 서버와 철저하게 분리되어 있기 때문에 직접적으로 연결된 부분만 신경 써주면 된다. 즉, 클라이언트는 서버의 구성과 상관없이 REST API 서버로 요청이 가능하다.

 

5. Code on Demand(Optional)

서버에서 클라이언트로 코드 또는 스크립트(로직)를 전달하여 클라이언트의 기능을 확장할 수 있다.

 

6. Uniform Interface

REST의 특징을 갖는 서비스는 편의를 위해 인터페이스에 대한 일정한 제약을 가지고 있다. 이러한 인터페이스를 통해 표준 형식으로 데이터를 전송할 수 있고, 어떤 플랫폼에서 요청을 하던 HTTP 프로토콜만 따른다면 자원의 상태를 교환할 수 있다.

---

REST API

API란?

API란 Application Programming Interface의 줄임말이다. 응용 프로그램에서 사용할 수 있도록 다른 응용 프로그램을 제어할 수 있게 만든 인터페이스를 뜻한다. API를 사용하면 내부 구현 로직을 알지 못해도 정의되어 있는 기능을 쉽게 사용할 수 있다.

여기서 인터페이스(Interface)란 어떤 장치 간 정보를 교환하기 위한 수단이나 방법을 의미하며, 대표적인 인터페이스의 예로는 마우스, 키보드, 터치패드 등이 있다.

 

REST API란?

REST API란 REST를 기반으로 HTTP 프로토콜 위에서 통신하는 API를 의미한다. 최근에 많은 API가 REST API 형태로 제공되고 있다.

RESTful이란 REST라는 아키텍처를 구현하는 웹 서비스를 나타내기 위해 사용하는 용어이다. 즉, REST API를 제공하는 웹 서비스를 RESTful 하다고 할 수 있다.

 

REST API의 특징

REST 기반으로 시스템을 분산하여 확장성과 재사용성을 높여 유지보수 및 운용을 편리하게 할 수 있다. REST는 HTTP 표준을 따르고 있기 때문에 다양한 프로그래밍 언어로 구현이 가능하다.

 

REST API 설계 규칙

URI는 정보의 자원을 표현해야 한다.

ㆍ 자원은 동사보다는 명사를 대문자보다는 소문자를 사용해야 한다.

    - GET /getmembers/1 (X) → GET /members/1 (O)

ㆍ 자원의 도큐먼트 이름은 단수 명사를 사용해야 한다. (도큐먼트 : 객체 인스턴스나 데이터베이스의 레코드와 유사한 개념)

ㆍ 자원의 컬렉션 이름은 복수 명사를 사용해야 한다. (컬렉션 : 서버에서 관리하는 디렉터리라는 리소스)

ㆍ 자원의 스토어 이름은 복수 명사를 사용해야 한다. (스토어 : 클라이언트에서 관리하는 리소스 저장소)

 

자원에 대한 행위는 HTTP Method로 표현한다.

ㆍ URI에 자원에 대한 행위가 들어가면 안 된다.

    - GET /members/delete/1 (X) → DELETE /members/1 (O)

ㆍ URI에 행위에 대한 동사 표현이 들어가면 안 된다.

    - GET /members/show/1 (X) → GET /members/1 (O)

    - GET /members/insert/2 (X) → POST /members/2 (O)

 

추가적인 설계 규칙

ㆍ 슬래시 구분자(/)는 계층 관계를 나타내는 데 사용한다.

    - http://restapi.example.com/houses/apartments

ㆍ URI의 마지막 문자로 슬래시(/)를 포함하지 않는다.

    - http://restapi.example.com/houses/apartments/ (X) → http://restapi.example.com/houses/apartments (O)

ㆍ URI가 길어질 경우 하이픈(-)을 통해서 가독성을 높일 수 있다.

ㆍ 언더바(_)는 사용하지 않는다.

ㆍ URI 경로에는 소문자가 적합하다.

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

 

REST API 설계 예시

 

 

응답 상태 코드

ㆍ 1XX : 전송 프로토콜 수준의 정보 교환을 의미한다.

ㆍ 2XX : 클라이언트 요청이 성공적으로 수행됨을 의미한다.

ㆍ 3XX : 클라이언트는 요청을 완료하기 위해 추가적인 행동을 취해야 함을 의미한다.

ㆍ 4XX : 클라이언트의 잘못된 요청을 의미한다.

ㆍ 5XX : 서버 쪽 오류로 인한 상태 코드를 의미한다.

---

출처

ㆍ https://www.youtube.com/watch?v=lceS3HbGXt4&list=PLlTylS8uB2fBOi6uzvMpojFrNe7sRmlzU&index=4&t=38s

ㆍ https://stitchcoding.tistory.com/21

ㆍ https://gmlwjd9405.github.io/2018/09/21/rest-and-restful.html