REST
정의
HTTP 통신에서 어떤 자원에 대한 CRUD 요청을 URI(Resource)와 Method로 표현하여 특정한 형태로 전달하는 방식
좀 더 풀어서 얘기하자면 HTTP URI(Uniform Resource Identifier)를 통해 자원을 명시하고, HTTP Method(POST,GET,PUT,DELETE)를 통해 해당 자원(URI)에 대한 CRUD Operation을 적용하는 것을 의미합니다.
- CRUD Operation란 컴퓨터 소프트웨어가 가지고 있는 기본적인 데이터 처리 기능을 의미합니다.
Create(생성,POST), Read(읽기,GET), Update(갱신,PUT), Delete(삭제)를 묶어서 일컫는 말입니다.
구성요소 3가지
- 자원 : HTTP URI
- 자원에 대한 행위 : HTTP Method
- 자원에 대한 행위의 내용 : HTTP Message Pay Load
특징
-
일관된 인터페이스 ( Uniform Interface )
Rest API는 HTTP를 사용하는 모든 플랫폼에서 요청가능하며, 느슨한 결함 형태 가지게 됨
-
무상태성 ( Stateless )
서버는 각각 요청을 별개인 것으로 인식하고 처리해야 합니다. 이전 요청이 다음 요청에 연관되서는 안됩니다. 이 무상태성은 서버의 처리방식에 일관성을 부여하고, 서버의 부담을 줄이기 위함입니다.
Rest API는 세션정보나 쿠키정보를 활용하여 작업을 위한 상태정보를 저장 및 관리하지 않습니다.
Rest API는 서비스 자유도가 높으며, 서버에서 불필요한 정보를 관리하지 않으므로 구현이 단순합니다. -
캐시 가능 ( Cacheable )
Rest API는 HTTP라는 기존의 웹표준을 그대로 사용하기 때문에, 웹의 기존 인프라를 그대로 활용가능합니다. 그러므로 Rest API도 캐싱 기능을 적용할 수 있는데 HTTP 프로토콜 표준에서 사용하는 Last-Modified Tag 또는 E-Tag를 이용하여 캐싱을 구현할 수 있고, 이것은 대량의 요청을 효율적으로 처리할 수 있게 도와줍니다.
-
서버 - 클라이언트 구조 ( Client- Server Architecture )
Rest API에서 자원을 가지고 있는 쪽이 서버, 자원을 요청하는 쪽이 클라이언트에 해당합니다. 서버는 API를 제공하며, 클라이언트는 사용자 인증, Context(세션,로그인정보) 등을 직접 관리하는 등의 역할을 확실히 구분시킴으로써 서로 간의 의존성을 줄입니다.
-
자체 표현 ( Self-Descriptiveness )
Rest API는 요청 메세지만 보고도 이를 쉽게 이해할 수 있는 자체 표현 구조로 되어있습니다. 예시로 JSON 형태의 Rest 메시지는 http://localhost:8080/board 로 게시글의 제목, 내용을 전달하고 있음을 손쉽게 이해할 수 있습니다. 또한 board라는 데이터를 추가(POST)하는 요청임을 파악할 수 있습니다.
HTTP POST , http://localhost:8080/board { "board":{ "title":"제목", "content":"내용" } } -
계층 구조 ( Layered System )
Rest API의 서버는 다중 계층으로 구성될 수 있으며 보안, 로드 밸런싱, 암호화 등을 위한 계층을 추가하여 구조를 변경할 수 있습니다. 또한 Proxy, Gateway와 같은 네트워크 기반의 중간매체를 사용할 수 있게 해줍니다. 하지만 클라이언트는 서버와 직접 통신하는지, 중간 서버와 통신하는지 알 수 없습니다.
REST API
정의
Representational State Transfer API
REST를 기반으로 만들어진 API를 의미합니다.
HTTP 프로토콜 장점을 살릴 수 있는 네트워크 기반 아키텍처
HTTP method + 모든 개체 Resource + URL 디자인(라우팅) 필요
최근 OpenAPI(누구나 사용할 수 있도록 공개된 API: 구글 맵, 공공 데이터 등), 마이크로 서비스(하나의 큰 애플리케이션을 여러 개의 작은 애플리케이션으로 쪼개어 변경과 조합이 가능하도록 만든 아키텍처) 등을 제공하는 업체 대부분은 REST API를 제공한다.
특징
- REST 기반으로 시스템을 분산해 확장성과 재사용성을 높여 유지보수 및 운용을 편리하게 할 수 있다.
- REST는 HTTP 표준을 기반으로 구현하므로, HTTP를 지원하는 프로그램 언어로 클라이언트, 서버를 구현할 수 있다.
- REST API를 제작하면 자바, C#, 웹 등을 이용해 클라이언트를 제작할 수 있다.
구성
Rest API는 Resource(자원), Method(행위), Representation of Resource(자원의 형태)로 구성
-
Resource - URI
서버는 유니크한 ID를 가지는 Resource를 가지고 있으며, 클라이언트는 이러한 Resource에 요청을 보냅니다. 이때 이러한 Resource는 URI에 해당합니다.
URI - Uniform Resource Identifier, 인터넷 상 자원을 식별하기 위한 문자열의 구성 ( URL을 포함 )
URL - Uniform Resource Locator, 인터넷 상 자원의 위치 ( 파일의 위치 )
-
Method
서버에 요청을 보내기 위한 방식으로 GET, POST, PUT, DELETE가 있습니다. CRUD 연산 중에서 처리를 위해 연산에 맞는 Method를 사용하여 서버에 요청을 보내야 합니다.
-
Representation of Resource
클라이언트와 서버가 데이터를 주고받는 형태로 json, xml, text, rss 등이 있습니다. 최근에 Key, Value를 활용하는 json을 주로 사용합니다.
설계 시 규칙
-
URI는 명사를 사용, 소문자를 사용
Bad Example http://khj93.com/Running/ Good Example http://khj93.com/run/ -
마지막에 슬래시를 포함하지 않기
Bad Example http://khj93.com/test/ Good Example http://khj93.com/test -
언더바 대신 하이폰을 사용 ( 가독성이 떨어지는 경우 )
Bad Example http://khj93.com/test_blog Good Example http://khj93.com/test-blog -
파일 확장자는 URI에 포함하지 않기
Bad Example http://khj93.com/photo.jpg Good Example http://khj93.com/photo -
행위를 포함하지 않기
Bad Example http://khj93.com/delete-post/1 Good Example http://khj93.com/post/1
- 질문
- 서버 설계때 rest api 사용할때와 사용하지 않을때의 차이 , 사용햇을때의 장점
- 의존성 분리의 차이에 대해서 궁금합니다.
- 네트워크면에서 질문할수있는거!
- Open API → REST API
