REST,REST API,RESTful 의 정의, 개념, 특징, 설계규칙 등 모든것을 총 정리해보자.
- API를 사용하면서, 그냥 사용하는것과 그 개념을 이해하고 사용하는것에 대한 아웃풋은 다르다고 생각합니다.
- 때문에 스스로 REST에 대한 개념들을 학습하고 정리하는 용도로 본 포스팅을 작성합니다.
1. REST의 의미 및 개념 정리
- REST(Representational State Transfer)는 Application 개발의 설계,제작을 사용하는 패턴과 기술들(이하 아키텍처) 중 하나입니다.
- 직역하면 대표 상태값 전송? 으로 알 수 있고, 의미는 자원(resource)의 표현(representation)에 의한 상태값의 전달을 의미합니다.
- 월드 와이드 웹(www)과 유사한 분산 하이퍼미디어 시스템을 위한 application 개발 아키텍처의 한 방식입니다.
- HTTP URI(Uniform Resource Identifier)를 통하여 자원을 명시하고, HTTP Method(POST/GET/PUT/DELETE)를 사용하여 자원에 대한 CRUD Operation을 적용하는 것을 의미합니다.
- 웹 서버의 리소스는 각자 이름을 가지고 있고, 클라이언트는 이러한 이름을 통해 원하는 정보를 찾을 수 있습니다.
- 이때 서버 리소스의 이름을 '통합 자원 식별자' 또는 URI라고 합니다.
2. REST를 써야하는 이유는?
- application 분리 및 통합에 사용됩니다. (프론트와 백엔드의 구분 및 통합 등)
- 다양한 클라이언트들이 등장하면서 커스터마이징 하는것보다 공수가 편하기 때문에 사용합니다.
- 한개의 데이터는 한 사이트에서만 사용되는 것이 아닌, 안드로이드 및 IOS 앱 등 디바이스와 통신할 수 있어야 함에 따라 REST형식으로 개발하여 자원을 효율적으로 이용하기 위하여 사용합니다.
3. REST 구성요소
- 첫 번째 자원(Resource) - URI
- 모든 리소스에는 각자의 고유한 이름(ID)을 가지고 있고 이 자원은 서버에 존재합니다.
- 서버 자원을 구별하는 ID는 아래와 같은 HTTP URI 형식을 가지고 있습니다.
- 클라이언트는 URI를 사용하여 자원을 지정하고, 해당 자원의 상태값에 대한 조작을 서버에 요청하게 됩니다.
/prudocts/products_id
- 두 번째 행위(Verb) - HTTP Method
- REST의 자원을 가지고 상태에 대한 조작을 요청하는 행위는 HTTP Method를 사용합니다.
- HTTP 프로토콜의 Method는 GET,POST,PUT,DELETE,HEAD 와 같은 메서드를 제공합니다.
- 세 번째 표현(Representation of Resource) - Response
- 요청하는 행위가 들어오면, 그에대한 결과를 응답해줘야할 의무가 있습니다.
- REST에서는 하나의 자원은 JSON,XML,TEXT,RSS 등 여러 형태의 REpresentation으로 나타낼 수 있습니다.
- 보통 JSON / XML 형식을 통해 응답합니다.
4.REST 특징
- Client And Server 구조
- 자원을 가지고 있는쪽을 자원을 제공(Serving)해주는 Server , 자원을 요청하는 쪽을 Client라 합니다.
- 서버는 API를 제공하며 비지니스로직에 대한 처리 및 저장 등을 책임집니다.
- 클라이언트에서는 application 사용자에 대한 인증 혹은 세션,로그인정보 등을 직접 관리합니다.
- 상호간 의존성이 줄어드는것이 특징입니다.
- Stateless[무상태]
- HTTP 프로토콜은 Stateless Protocol입니다. 때문에 REST 역시 Stateless의 형태를 갖습니다.
- Client의 세션,쿠키(context)와 같은 정보를 Server에 저장하지 않으므로 구현이 단순해집니다.
- Server는 각각의 요청들을 별개의 것으로 인식하여 처리하게됩니다.
- 이전 요청이 다음 요청에 대한 처리에 연관되어서는 안되야 합니다.
- 이전 요청이 DB를 수정하여 DB에 의해 바뀌는것은 허용됩니다.
- 각 Server는 Client의 요청만을 단순 처리합니다.
- Server의 처리 방식에 일관성을 부여하기 때문에 부담이 줄어들면서 서비스의 자유도가 높아집니다.
- Cacheable[캐시 처리]
- 웹 표준인 HTTP 프로토콜을 사용ㅎㄱ 때문에 기존 웹에서 사용하는 인프라를 그대로 활용할 수 있습니다.
- HTTP가 가진 강력한 특징인 캐싱처리 기능을 적용할 수 있습니다.
- HTTP프로토콜 표준에서 사용하는 Last-Modified태그 혹은 E-Tag를 이용하여 캐싱 구현이 가능합니다.
- 대량의 요청을 효율적으로 처리하기 위해 캐시가 요구됩니다.
- 캐시 사용을 통해 응답시간이 빨리지게 되고, REST Server 트랜잭션이 발생하지 않기 때문에 전체 응답시간, 성능 등 서버의 자원 이용률 향상에 용이합니다.
- 웹 표준인 HTTP 프로토콜을 사용ㅎㄱ 때문에 기존 웹에서 사용하는 인프라를 그대로 활용할 수 있습니다.
- Layerd System[계층화]
- Client는 REST API Server만 호출합니다.
- REST Server는 비즈니스 로직을 수행하고 앞단에 보안/로드밸런싱/암호화/사용자 인증 등을 추가하여 구조상의 유연성을 줄 수 있고 공유캐시 등을 통한 확장성과 보안성을 향상시킬 수 있기 때문에 다중 계층으로 구성될 수 있습니다.
- PROXY, GateWay와 같은 네트워크 기반의 중간 매체를 사용할 수 있습니다.
- Code-On-Demand
- 클라이언트는 리소스에 대한 표현을 응답으로 받고 처리해야 하는데, 어떻게 처리해야 할지에 대한 code를 서버가 제공하는것을 의미합니다.
- HTML에서의 javascript가 대표적인 예로, 반드시 충족할 필요는 없으며 보안상의 이슈로 권장하지 않는 분위기입니다.
- Uniform Interface[인터페이스 일관성]
- URI로 지정한 Resource에 대한 조작을 통일되고 한정적인 인터페이스로 수행합니다.
- HTTP 표준 프로토콜을 따르는 모든 플랫폼에서 사용이 가능하기 때문에 특정 언어나 기술에 종속되지 않습니다.
5.REST API란?
- 우선 API(Application Programming Interface)란 데이터와 기능의 집합을 제공하여 디바이스 프로그램간 상호작용을 촉진하고, 서로의 정보를 교환토록 하는것을 의미합니다.
- REST API는 REST기반으로 서비스 API를 구현한 것을 의미합니다.
- 최근에는 OpenAPI, 마이크로 서비스(큰 애플리케이션을 작은 애플리케이션 여러개로 쪼개어 변경 및 조합이 가능하도록 만든 아키텍처) 등을 제공하는 업체 대부분은 REST API를 제공하고 있습니다.
- 사내 시스템들도 REST 기반으로 시스템을 분산하여 확장성과 재사용성을 높여 유지보수 및 운용을 편리하게 할 수 있습니다.
- REST는 HTTP 표준을 기반으로 구현하기 때문에, HTTP를 지원하는 프로그래밍 언어로 클라이언트와 서버를 구현할 수 있습니다.
6.REST API 설계의 기본 원칙
도큐먼트 : 데이터베이스의 row단위 혹은, 리스트 컬렉션의 하나의 객체 단위로 단일 정보를 포함하고 있는 데이터라고 생각합니다.
컬렉션 : 도큐먼트들의 집합으로 관리 주체가 서버, 컬렉션은 클라이언트에서 새로운 리소스를 제안해서 올릴 수 있고 결정은 서버가 합니다.
스토어 : 컬렉션과 같이 도큐먼트들의 집합이며 관리 주체는 클라이언트입니다. 기존의 리소스를 스토어에 추가하거나 삭제 변경할 수 있지만 새로운 리소스를 생성할 수 없습니다.
컨트롤러 : 컬렉션,스토어의 메서드 기능이라고 생각하면 됩니다. HTTP Method를 제외한 특정한 기능을 요구할 때 사용합니다.
- URI는 정보의 자원을 표현해야 합니다.
- resource는 동사보다 명사를, 대문자보다 소문자를 사용합니다.
- resource의 도큐먼트 이름으로는 단수 명사를 사용합니다.
- resource 컬렉션,스토어 이름으로는 복수 명사를 사용합니다.
#예제
GET /product/1 // X
GET /products/1 // O
- 자원에 대한 행위는 HTTP Method(GET,PUT,POST,DELETE)로 표현합니다.
- URI에 HTTP Method를 삽입하지 않습니다.
- URL에 행위에 관련된 동사표현을 삽입하지 않습니다.
- 경로 부분 안에서 변하는 부분은 유일한 값으로 대체합니다.
#예제
GET /products/update/1 // X
PUT /products/1 // O
GET /products/show/1 // X
GET /products/1 // O
7.REST API 설계 규칙
- 슬래시(/) 구분자는 계층관계를 나타낼때 사용합니다.
- URI 마지막 문자는 슬래시(/)구분자로 끝내지 않습니다.
- 하이픈(-) 구분자는 URL 가독성을 높이는데 사용합니다.
- 언더바(_) 구분자는 URI에 사용하지 않습니다.
- URI 경로에는 소문자를 사용합니다.
- 파일확장자는 URI에 포함하지 않습니다.
- 이미지 등 가져올때는 Accept Header를 사용합니다.
- 리소스간에 연관 관계가 있는경우는 아래와 같이 사용합니다.
- /리소스1/리소스1 id/리소스2
- GET : /users/{userid}/devices (일반적으로 소유 'has'의 관계를 표현할 때 사용합니다)
- REST API 설계 예시
- 참고 응상태 코드
- 1xx : 전송 프로토콜 수준의 정보 교환
- 2xx : 클라이언트 요청이 성공적으로 수행됨
- 3xx : 클라이언트는 요청을 완료하기 위해 추가적인 행동을 취해야 함
- 4xx : 클라이언트의 잘못되 요청
- 5xx : 서버쪽 오류로 인한 상태값
8.RESTful이란?
- REST라는 아키텍처를 구현하는 웹서비스를 지칭합니다. 즉 REST원리를 따르는 시스템을 RESTful이란 용어로 지칭합니다.
- 이해하기 쉽고 사용하기 쉬운 REST API를 만드는 것에 목적이 있으며 RESTful한 API를 구현하는 근본적인 목적이 성능향상에 있는것이 아니라, 일관적인 컨벤션을 통한 API의 이해도 및 호환성을 높이는 것이 주 목적입니다. 성능이 중요한 상황에서는 굳이 RESTful한 API를 고집할 필요는 없다고 생각합니다.
관련글
'API' 카테고리의 다른 글
[Google] reCAPTCHA 'invalid-input-secret' 이슈 (0) | 2022.02.08 |
---|