REST, REST API, RESTful 특징
REST (REpresentational State Transfer)
REST는 HTTP를 기반으로 필요한 자원에 접근하는 방식을 정해놓은 아키텍처라고 할 수 있다. 여기서 자원이란 소프트웨어가 관리하는 모든 것(문서, 그림, 데이터 등)을 의미한다.
REST는 웹의 기존 기술과 HTTP 프로토콜을 그대로 활용하기 때문에 웹의 장점을 최대한 활용할 수 있다.
REST는 월드 와이드 웹(www)과 같은 분산 하이퍼 미디어 시스템을 위한 소프트웨어 개발 아키텍처의 한 형식이다.
이걸 단순하게 정리하자면, "REST란 HTTP 를 잘 사용하기 위한 아키텍쳐 스타일" 이다.
REST 구성 요소
1) 자원(Resource)
모든 자원에는 고유한 ID가 존재하고, 이 자원은 서버에 존재한다. REST는 자원에 접근할 때 URI(Uniform Resource Identifier)를 이용한다. 여기서 URI는 자원의 위치를 나타내는 일종의 식별자이다.
ex) 자원 ID : 2 / 자원 : 초급반 / URI : https://(도메인)/classes/2
{
"results" : [
{"idx" : 1, "name": "예비반"},
{"idx" : 2, "name": "초급반"}
]
}2) 메서드(Method)
REST는 기본적으로 HTTP 메서드를 사용한다. 그 종류에는 GET, POST, PUT, DELETE 등이 존재하고, 각각 다음과 같은 역할을 한다.GET : 해당 리소스를 조회한다.
POST : 해당 리소스를 생성한다
PUT : 해당 리소스를 수정한다.
DELETE : 해당 리소스를 삭제한다.
위와 같은 연산을 CRUD(Create, Research, Update, Delete) 연산이라고 한다.
ex) GET .../board/article/{articleid} -> .../board/article에 위치한 {articleid}를 가진 자원을 조회한다.
3) 메시지(Message)
메시지는 HTTP header, body, 응답 상태 코드 등으로 구성되어 있다. 간단하게 설명하자면 header에는 body에 어떤 형식으로 데이터가 담겼는지 표시하고, body는 자원에 대한 정보를 JSON, XML 등으로 전달한다. 응답 상태 코드는 200~500 사이의 숫자로 클라이언트의 요청에 대한 상태를 나타내 준다.REST의 특징
- Server-Client(서버-클라이언트 구조)
자원이 있는 쪽이 서버, 자원을 요청하는 쪽이 클라이언트가 된다. 서버는 API를 제공하고 비즈니스 로직 처리 및 저장을 책임진다.- Stateless(무상태)
REST는 HTTP를 기본으로 하기 때문에 무상태이다. 여기서 무상태란 클라이언트의 상태(State)를 서버에 저장하지 않는다는 뜻이다. 따라서 서버는 클라이언트의 요청을 완전히 별개의 것으로 인식하고 처리한다. 따라서 이전의 요청이 다음의 요청에 연관되지 않는다. 이를 통해 서버의 처리 방식에 일관성을 부여하고 부담이 줄어들게 된다.- Cacheable(캐시 처리 가능)
HTTP의 캐싱 기능을 적용할 수 있다. 즉, 대량의 요청을 효율적으로 처리하기 위한 캐시를 사용할 수 있다. 캐시 사용을 통해 응답 시간이 빨라지고 성능, 서버의 자원 이용률을 향상할 수 있다.- Layered System(계층화)
클라이언트는 REST API 서버만 호출한다. REST 서버는 다중 계층으로 구성될 수 있다. API 서버는 순수 비즈니스 로직을 수행하고 그 앞단에 보안, 로드 밸런싱, 암호화, 사용자 인증 등을 추가하여 구조상의 유연성을 줄 수 있다.- Uniform Interface(인터페이스 일관성)
URI로 지정한 자원에 대한 조작을 통일되고 한정적인 인터페이스로 수행한다.HTTP 표준 프로토콜에 따르는 모든 플랫폼에서 사용이 가능하다. 따라서 특정 언어나 기술에 종속되지 않는다.
**
REST API
- REST 기반으로 서비스 API를 구현한 것- OpenAPI(누구나 사용할 수 있는 공개된 API : 구글맵, 네이버 지도의 API 등 ) 는 대부분 REST API를 제공한다.
** API(Application Programming Interface)란
데이터와 기능의 집합을 제공하여 컴퓨터 프로그램간 상호작용을 촉진하며, 서로 정보를 교환가능 하도록 하는 것
REST API 특징
- 사내 시스템들도 REST 기반으로 시스템을 분산해 확장성과 재사용성을 높여 유지보수 및 운용을 편리하게 할 수 있다.
- REST는 HTTP 표준을 기반으로 구현하므로, HTTP를 지원하는 프로그램 언어로 클라이언트, 서버를 구현할 수 있다.
- 즉, REST API를 제작하면 델파이 클라이언트 뿐 아니라, 자바, C#, 웹 등을 이용해 클라이언트를 제작할 수 있다.
REST API의 설계 규칙
-
슬래시 구분자(/ )는 계층 관계를 나타내는데 사용한다.
ex) http://restapi.example.com/houses/apartments -
URI 마지막 문자로 슬래시(/ )를 포함하지 않는다.
-
URI에 포함되는 모든 글자는 리소스의 유일한 식별자로 사용되어야 하며 URI가 다르다는 것은 리소스가 다르다는 것이고, 역으로 리소스가 다르면 URI도 달라져야 한다.
-
REST API는 분명한 URI를 만들어 통신을 해야 하기 때문에 혼동을 주지 않도록 URI 경로의 마지막에는 슬래시(/)를 사용하지 않는다.
ex) http://restapi.example.com/houses/apartments/ (X) -
하이픈(- )은 URI 가독성을 높이는데 사용
불가피하게 긴 URI경로를 사용하게 된다면 하이픈을 사용해 가독성을 높인다. -
밑줄(_ )은 URI에 사용하지 않는다.
밑줄은 보기 어렵거나 밑줄 때문에 문자가 가려지기도 하므로 가독성을 위해 밑줄은 사용하지 않는다. -
URI 경로에는 소문자가 적합하다.
URI 경로에 대문자 사용은 피하도록 한다.
RFC 3986(URI 문법 형식)은 URI 스키마와 호스트를 제외하고는 대소문자를 구별하도록 규정하기 때문 -
파일확장자는 URI에 포함하지 않는다.
REST API에서는 메시지 바디 내용의 포맷을 나타내기 위한 파일 확장자를 URI 안에 포함시키지 않는다.
Accept header를 사용한다.ex) http://restapi.example.com/members/soccer/345/photo.jpg (X)ex) GET / members/soccer/345/photo HTTP/1.1 Host: restapi.example.com Accept: image/jpg (O) -
리소스 간에는 연관 관계가 있는 경우
/리소스명/리소스 ID/관계가 있는 다른 리소스명
ex) GET : /users/{userid}/devices (일반적으로 소유 ‘has’의 관계를 표현할 때)
RESTful
: REST의 특징을 기반으로 서비스 API를 구현한 것
RESTful의 목적
- 이해하기 쉽고 사용하기 쉬운 REST API를 만드는 것
- RESTful한 API를 구현하는 근본적인 목적이 성능 향상에 있는 것이 아니라 일관적인 컨벤션을 통한 API의 이해도 및 호환성을 높이는 것이 주 동기이니, 성능이 중요한 상황에서는 굳이 RESTful한 API를 구현할 필요는 없다.
- RESTful 하지 못한 경우
ex1) CRUD 기능을 모두 POST로만 처리하는 API
ex2) route에 resource, id 외의 정보가 들어가는 경우(/students/updateName)
