REST, REST API, RESTful API
1. 개요
비슷비슷해보이는 REST, REST API, RESTful API에 대해 정리해보자
2. REST
REST는 "REpresentational State Transfer"의 약어로, HTTP 통신을 활용하기 위해 고안된 아키텍처이다.
인터넷 상의 자원을 URI(Uniform Resource Identifier)로 나타낼 수 있음을 의미한다.
즉, 자원을 이름으로 구분하여 해당 자원의 상태(정보)를 주고받는 모든 것을 의미하며 API 설계 방식의 일종이다.
클라이언트는 URI로 표현된 자원을 HTTP 메서드를 이용해 CRUD 연산을 할 수 있다. State Transfer는 자원의 상태를 주고받는 것(= 요청받은 자원의 상태를 전달하는 것)을 의미한다.
REST는 HTTP URI(Uniform Resource Identifier)를 통해 자원(Resource)을 명명하고,
HTTP Method(POST, GET, PUT, DELETE)를 통해 해당 자원에 대한 CRUD 작업(Operation)을 적용한다.
REST 원리를 따르는 시스템은 RESTful이란 용어로 지칭된다.
3. REST 특징
1. Server-Client(서버-클라이언트 구조)
- 자원이 있는 쪽이 서버, 자원을 요청하는 쪽이 클라이언트가 된다.
- 클라이언트와 서버 간에 요청-응답의 독립적인 구조를 갖는다.
- 클라이언트는 서버에 요청을 보내고 응답을 대기한다. 서버는 클라이언트의 요청에 응답한다.
2. Stateless(무상태)
- HTTP 프로토콜은 Stateless Protocol이므로 REST 역시 무상태성을 갖는다.
- 서버에서는 클라이언트의 요청을 저장하거나 관리하지 않는다.
- 세션과 쿠키와 같은 Context 정보를 신경쓰지 않아도 되므로 구현이 단순해진다.
- 서버는 각각의 요청을 완전히 별개의 것으로 인식하고 처리한다.
- 각 API 서버는 해당 Client의 요청만을 단순 처리한다.
- 즉, 이전 요청이 다음 요청의 처리에 연관되지 않는다.
3. Cacheable(캐시 처리 가능)
- 웹 표준 HTTP 프로토콜을 그대로 사용하므로 웹에서 사용하는 기존의 인프라를 그대로 활용할 수 있다.
- HTTP가 가진 가장 강력한 특징 중 하나인 캐싱 기능을 적용할 수 있다..
- 대량의 요청을 효율적으로 처리하기 위해 캐시가 요구된다.
- 캐시 사용을 통해 응답시간이 빨라지고 REST Server 트랜잭션이 발생하지 않기 때문에 전체 응답시간, 성능, 서버의 자원 이용률을 향상시킬 수 있다.
4. Layered System(계층화)
- Client는 REST API Server만 호출한다.
- REST Server는 다중 계층으로 구성될 수 있다.
- API Server는 순수 비즈니스 로직을 수행하고 그 앞단에 보안, 로드밸런싱, 암호화, 사용자 인증 등을 추가하여 구조상의 유연성을 줄 수 있다.
5. Uniform Interface(인터페이스 일관성)
- 자원을 나타내는 URI를 HTTP메서드로 조작하는 일관된 인터페이스를 사용한다. 따라서 HTTP를 따르는 모든 플랫폼에서 REST를 사용할 수 있다.
4. REST API
REST API는 REST를 기반으로 한 API를 뜻한다.
API란 다른 소프트웨어에 서비스를 제공하기 위한 소프트웨어 인터페이스다. 즉, REST API는 REST를 기반으로 한 인터페이스라고 할 수 있다.
4.1 REST API의 구성
REST API에서 자원의 식별은 URI로 하고 자원에 대한 행위(처리)는 HTTP 메서드로 나타낸다.
그리고 전달되는 데이터는 JSON 또는 XML 등으로 나타낸다.
4.2 REST API 작동과정
- 클라이언트가 URI로 식별한 자원에 대해 HTTP 메서드를 사용해 REST API로 요청한다.
- REST API가 HTTP 요청 메시지에 실려 서버에 전달된다.
- 서버에서는 수신한 HTTP 요청 메시지를바탕으로 요청사항을 확인해 처리하고 HTTP 응답을 반환한다. 응답에는 요청에 대한 처리 성공 여부와 정보를 포함한다.
- 응답 메시지는 자원에 대한 정보를 JSON 또는 XML 등의 형태로 포함한다. 클라이언트는 해당 형태의 정보를 수신한다.
5. RESTful API의 이점
REST 규칙을 지키며 API를 제공하는 서비스를 RESTful하다고 한다.
확장성
- REST API는 사용되는 기술과 독립적이다. API 설계에 영향을 주지 않고 다양한 프로그래밍 언어로 클라이언트 및 서버 애플리케이션을 모두 작성할 수 있다. 또한 통신에 영향을 주지 않고 양쪽의 기본 기술을 변경할 수 있다.
유연성
- RESTful 웹 서비스는 완전한 클라이언트-서버 분리를 지원한다. 각 부분이 독립적으로 발전할 수 있도록 다양한 서버 구성 요소를 단순화하고 분리한다. 서버 애플리케이션의 플랫폼 또는 기술 변경은 클라이언트 애플리케이션에 영향을 주지 않는다.
- 애플리케이션 함수를 계층화하는 기능은 유연성을 더욱 향상시킨다. 예를 들어, 개발자는 애플리케이션 로직을 다시 작성하지 않고도 데이터베이스 계층을 변경할 수 있다.
독립성
- REST API를 구현하는 시스템은 REST가 클라이언트-서버 상호 작용을 최적화하기 때문에 효율적으로 크기 조정할 수 있다. 무상태는 서버가 과거 클라이언트 요청 정보를 유지할 필요가 없기 때문에 서버 로드를 제거한다. 잘 관리된 캐싱은 일부 클라이언트-서버 상호 작용을 부분적으로 또는 완전히 제거한다. 이러한 모든 기능은 성능을 저하시키는 통신 병목 현상을 일으키지 않으면서 확장성을 지원한다.
6. REST API 설계의 기본규칙
REST API 설계 시 가장 중요한 항목은 다음의 2가지로 요약할 수 있다.
첫 번째, URI는 정보의 자원을 표현해야 한다.
두 번째, 자원에 대한 행위는 HTTP Method(GET, POST, PUT, DELETE)로 표현한다.
다음에 제시된 URI 예는 REST를 제대로 적용하지 않은 URI이다. -> GET /members/delete/1
URI는 자원을 표현하는데 중점을 두어야 한다. delete와 같은 행위에 대한 표현이 들어가서는 안된다. 자원에 대한 행위는 HTTP Method(GET, POST, PUT, DELETE 등)로 표현한다.
위의 잘못된 URI 를 HTTP Method를 통해 수정해 보면 다음과 같다. -> DELETE /members/1
자원에 대한 행위는 HTTP Method(GET, PUT, POST, DELETE 등)로 표현한다.
URI는 자원을 표현하는 데에 집중하고 행위에 대한 정의는 HTTP METHOD를 통해 하는 것이 REST한 API를 설계하는 중심 규칙이다.
8. REST API 설계 시 주의할 점
1) 슬래시 구분자(/)는 계층 관계를 나타내는데 사용
http://restapi.example.com/houses/apartments
http://restapi.example.com/animals/mammals/whales
2) URI 마지막 문자로 슬래시(/)를 포함하지 않는다.
URI에 포함되는 모든 글자는 리소스의 유일한 식별자로 사용되어야 하며 URI가 다르다는 것은 리소스가 다르다는 것이고, 역으로 리소스가 다르면 URI도 달라져야 한다.
REST API는 분명한 URI를 만들어 통신을 해야 하기 때문에 혼동을 주지 않도록 URI 경로의 마지막에는 슬래시(/)를 사용하지 않는다.
http://restapi.example.com/houses/apartments/ (X)
http://restapi.example.com/houses/apartments (0)
3) 하이픈(-)은 URI 가독성을 높이는데 사용한다.
URI를 쉽게 읽고 해석하기 위해, 불가피하게 긴 URI경로를 사용하게 된다면 하이픈을 사용해 가독성을 높일 수 있다.
4) 밑줄(_)은 URI에 사용하지 않는다.
글꼴에 따라 다르긴 하지만 밑줄은 보기 어렵거나 밑줄 때문에 문자가 가려지기도 한다. 이런 문제를 피하기 위해 밑줄 대신 하이픈(-)을 사용하는 것이 좋다.(가독성)
5) URI 경로에는 소문자가 적합하다.
URI 경로에 대문자 사용은 피하도록 해야 한다.
대소문자에 따라 다른 리소스로 인식하게 되기때문이다. RFC 3986(URI 문법 형식)은 URI 스키마와 호스트를 제외하고는 대소문자를 구별하도록 규정하고 있다.
RFC 3986 is the URI (Unified Resource Identifier) Syntax document
6) 파일 확장자는 URI에 포함시키지 않는다.
http://restapi.example.com/members/soccer/345/photo.jpg (X)
REST API에서는 메시지 바디 내용의 포맷을 나타내기 위한 파일 확장자를 URI 안에 포함시키지않는다.
대신 Accept 헤더를 사용한다.
-> GET / members/soccer/345/photo HTTP/1.1 Host: restapi.example.com Accept: image/jpg
9. 정리
REST는 웹에서 데이터를 주고받기 위한 아키텍처이다.
HTTP를 기반으로 하기에 HTTP를 따르는 모든 플랫폼에서 별도의 인프라 구축 없이 REST를 사용할 수 있다.
클라이언트-서버 구조, 무상태성, 일관된 인터페이스 등의 특징을 가지고 있다.
REST API는 REST를 기반으로 한 API를 뜻한다.
RESTful API는 클라이언트와 서버 간의 통신을 위한 규칙을 정의하고, HTTP를 기반으로 데이터를 주고받는다.
클라이언트는 URI를 사용하여 서버의 리소스에 접근하고, HTTP 메서드(GET, POST, PUT, DELETE 등)를 사용하여 해당 리소스를 조작할 수 있다.
* REST API 활용 예제 정리
REST API 실습 예제 정리
문제 1. entity 패키지를 만들고 다음과 같은 필드를 갖는 Friend 라는 엔티티 클래스를 생성한다. id (int - PK, auto increment ) fname (String) fage (Integer) 2. repository 패키지를 만들고 CRUD 가 가능한 FriendReposito
ek0129.tistory.com
참고
이수진, 『기술 면접 대비 CS 전공 핵심요약집』, 길벗