REST (Representational State Transfer)
★ REST란?
- 자원을 이름으로 구분하여 해당 자원의 상태(정보)를 주고 받는 모든 것을 의미
- 즉, 자원(resource)의 표현(representation)에 의한 상태 전달을 일컫는다
* 자원: 해당 소프트웨어가 관리하는 모든 것 ex) 문서, 그림, 데이터, 해당 소프트웨어 자체 등
* 표현: 그 자원을 표현하기 위한 이름 ex) DB학생 정보가 자원일 때, "students"를 자원의 표현이라고 함
* 상태(정보) 전달: 데이터가 요청되어지는 시점에서 자원의 상태를 전달 ex) JSON이나 XML을 통해 주고 받는 것이 일반적
- ROA(Resource Oriented Architecture)를 따르는 웹 서비스 아키텍처
- HTTP URI(Uniform Resource Identifier)를 통해 자원을 명시하고, HTTP Method(POST, GET, PUT, DELETE)를 통해 해당 자원에 대한 CRUD Operation을 적용하는 것을 의미
REST CRUD
■ Create : 생성 (POST)
■ Read : 조회 (GET)
■ Update : 수정 (PUT)
■ Delete: 삭제 (DELETE)
"URI와 HTTP 메소드를 이용해 객체화된 서비스에 접근하는 것"
REST 구성 요소
■ 자원 (Resource): URI
- 모든 자원에 고유한 ID가 존재하고, 이 자원은 Server에 존재
- 자원을 구별하는 ID는 '/groups/:group_id'와 같은 HTTP URI
- Client는 URI를 이용해서 자원을 지정하고 해당 자원의 상태에 대한 조작을 Server에 요청
■ 행위 (Verb): HTTP Method
- HTTP 프로토콜의 Method를 사용
- HTTP 프로토콜은 GET, POST, PUT, DELETE와 같은 메서드를 제공
■ 표현 (Representation of Resource)
- Client가 자원의 상태에 대한 조작을 요청하면 Server는 이에 적절한 응답(Representation)을 보냄
- REST에서 하나의 자원은 JSON, XML, TEXT, RSS 등 여러 형태로 나타낼 수 있음
- JSON 혹은 XML을 통해 데이터를 주고 받는 것이 일반적
REST 특징
■ Server-Client 구조 (자원이 있는 쪽이 Server, 자원을 요청하는 쪽이 Client)
- REST Server는 API를 제공하고 비지니스 로직 처리 및 저장을 책임지고
- REST Client는 사용자 인증이나 context(세션, 로그인 정보) 등을 직접 관리하고 책임
- REST를 사용하면 서버와 클라이언트 간 의존성이 줄어듦
■ Stateless(무상태)
- 이전, 이후에 대한 직접적인 정보가 필요없이 직관적인 오브젝트에의 접근으로 서비스를 처리
- 세션정보를 보관할 필요가 없기 때문에, 서비스의 자유도 또한 높아지고 로드밸런싱이나 기타 유연한 아키텍처의 적용이 가능
- 쿠키와 세션이 필요없음
■ Cacheable(캐시 처리 가능)
- 웹 표준 HTTP 프로토콜을 그대로 사용하므로 웹에서 사용하는 기존의 인프라를 그대로 활용 가능
- 캐시 사용을 통해 응답시간이 빨라지고 REST Server 트랜잭션이 발생하지 않기 때문에 전체 응답시간, 성능, 서버의 자원 이용률이 향상됨
■ Layered System(계층화)
- Client는 REST API Server만 호출
- REST Server는 다중 계층으로 구성 가능
- Proxy, Gateway와 같은 네트워크 기반의 중간 매체를 사용 가능
■ Addressability(URI 접근)
- REST는 모든 유일한 Object에 대해 유일하고 직관적인 URI를 통해 접근하도록 함
- 웹 사이트의 이미지, 텍스트, DB 내용 등의 모든 자원에 고유한 ID인 HTTP URI를 부여
- Uniform Interface(인터페이스 일관성): URI로 지정한 리소스 조작을 통일되고 한정적인 인터페이스로 수행
REST 장점
- HTTP 프로토콜의 인프라를 그대로 사용하기 때문에 REST API 사용을 위한 별도의 인프라를 구축할 필요가 없음
- HTTP 프로토콜의 표준을 최대한 활용하여 여러 추가적인 장점을 함께 사용 가능
- HTTP 표준 프로토콜에 따르는 모든 플랫폼에서 사용 가능
- Hypermedia API의 기본을 충실히 지키면서 범용성을 보장
- REST API 메시지가 의도하는 바를 명확하게 나타내므로 의도하는 바를 쉽게 파악 가능
- 여러가지 서비스 디자인에서 생길 수 있는 문제를 최소화
- 서버와 클라이언트의 역할을 명확하게 분리
REST 단점
- 표준이 존재하지 않음
- 사용할 수 있는 메소드가 4가지밖에 없음
- HTTP Method 형태가 제한적
- 구형 브라우저가 지원해주지 못하는 부분 (PUT, DELETE, pushSTate)가 존재
REST의 필요성
- 애플리케이션 분리 및 통합을 해야할 때
- 다양한 클라이언트들이 등장했을 때
- 다양한 브라우저, 안드로이드폰, 아이폰과 같은 모바일 디바이스에서도 통신 가능한 서버 프로그램이 필요할 때
- 멀티 플랫폼에 대한 지원을 위해 서비스 자원에 대한 아키텍처가 필요할 때
★★ 스프링에서의 REST
@ResponseBody 애노테이션을 지원하게 되면서 REST 방식의 처리를 지원, @RestController를 통해 구현 가능
REST API
★ REST API란?
- REST 기반으로 서비스 API를 구현한 것
- 최근 OpenAPI 마이크로 서비스 등을 제공하는 업체 대부분은 REST API를 제공
REST API 특징
■ 사내 시스템들도 REST 기반으로 시스템을 분산해 확장성과 재사용성을 높여 유지보수 및 운용을 편리하게 가능
■ REST는 HTTP 표준을 기반으로 구현하므로, HTTP를 지원하는 프로그램 언어로 클라이언트, 서버를 구현 가능
■ REST API를 제작하면 델파이 클라이언트 뿐 아니라 자바, C#, 웹 등을 이용해 클라이언트 제작 가능
REST API 설계 기본 규칙
■ URI는 정보의 자원을 표현해야 한다
- resource는 동사보다는 명사를, 대문자보다는 소문자를 사용
- resource의 도큐먼트 이름으로는 단수 명사를 사용
- resource의 컬렉션 이름으로는 복수 명사를 사용
- resource의 스토어 이름으로는 복수 명사를 사용
■ 자원에 대한 행위는 HTTP Method(GET, PUT, POST, DELETE 등)로 표현한다
- URI에 HTTP Method가 들어가면 안됨
- URI에 행위에 대한 동사 표현이 들어가면 안됨 (CRUD 기능을 나타내는 것은 URI에 사용하지 않음)
- 경로 부분 중 변하는 부분은 유일한 값으로 대체 (id는 하나의 특정 resource를 나타내는 고유 값)
■ 슬래시 구분자( / )는 계층 관계를 나타내는 데 사용한다
■ URI 마지막 문자로 슬래시 구분자( / )를 포함하지 않는다
■ 하이픈( - )은 URI 가독성을 높이는데 사용한다
■ 밑줄 ( _ )은 URI에 사용하지 않는다
■ URI 경로에는 소문자가 적합하다 (대문자 사용은 피하도록 한다)
■ 파일 확장자는 URI에 포함하지 않는다
- Accept header를 사용
■ 리소스 간의 연관 관계가 있는 경우 /리소스명/리소스 ID/관계가 있는 다른 리소스명
RESTful
★ RESTful이란?
- REST라는 아키텍처를 구현하는 웹 서비스를 나타내기 위해 사용되는 용어
- "REST API" 를 제공하는 웹 서비스를 "RESTful"하다고 할 수 있음
- 즉, REST 원리를 따르는 시스템은 RESTful이란 용어로 지칭됨
RESTful 목적
- 이해하기 쉽고 사용하기 쉬운 REST API를 만들기 위해
- RESTful한 API를 구현하는 근본적인 목적은 성능 향상이 아니라 일관적인 컨벤션을 통한 API의 이해도 및 호환성을 높이는 것이 주 목적
★★ RESTful 하지 못한 경우?
- CRUD 기능을 모두 POST로만 처리하는 API
- 라우트(route)에 Resource, id 외의 정보가 들어간 경우(/books/updateName)
'STUDY > ETC' 카테고리의 다른 글
| SQL 기본 문법 - DML (0) | 2023.12.09 |
|---|---|
| Github 사용법 (0) | 2023.12.09 |
