REST API
REST의 탄생 배경
-
프론트엔드와 백엔드가 분리되기 시작하면서 등장
-
새로운 서비스 개발을 위해 개발작업 진행
-
JSON 형태로 데이터를 제공하는 API를 제공하자고 동의
-
RequestMethod(HTTP: GET, POST, PUT, DELETE)와 URL을 이용한 정의
-
View 영역이 포함되지 않은 서버사이드(Server-side) 개발을 진행
-
-
멀티플랫폼에 대한 지원을 위해 서비스 자원에 대한 아키텍처를 세우고 이용하는 방법을 모색
-
OPEN API
개념 설명
API 또는 애플리케이션 프로그래밍 인터페이스는 애플리케이션이나 디바이스가 서로 간에 연결하여 통신할 수 있는 방법을 정의하는 규칙 세트이다.
REST API는 REST(REpresentational State Transfer) 아키텍처 스타일의 디자인 원칙을 준수하는 API이다.
-
REST의 구체적인 개념
HTTP URI(Uniform Resource Identifier)를 통해 자원(Resource)을 명시하고, HTTP Method(POST, GET, PUT, DELETE)를 통해 해당 자원에 대한 CRUD Operation을 적용하는 것을 의미한다.
-
즉, REST는 자원 기반의 구조(ROA, Resource Oriented Architecture) 설계의 중심에 Resource가 있고 HTTP Method를 통해 Resource를 처리하도록 설계된 아키텍쳐를 의미한다.
-
웹 사이트의 이미지, 텍스트, DB 내용 등의 모든 자원에 고유한 ID인 HTTP URI를 부여한다.
-
CRUD Operation
-
Create : 생성(POST)
-
Read : 조회(GET)
-
Update : 수정(PUT)
-
Delete : 삭제(DELETE)
-
HEAD: header 정보 조회(HEAD)
-
-
-
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 등 여러 형태의 Representation으로 나타내어 질 수 있다.
-
JSON 혹은 XML를 통해 데이터를 주고 받는 것이 일반적이다.
-
-
통신 과정 설명
RESTful의 의미는?
REST의 아래 조건을 만족하고, 규칙에 맞게 작성한 것이 RESTful하다고 할 수 있다.
-
조건
-
Uniform interface
일관적인 인터페이스로 구성되어야 한다. 즉, 어떤 플랫폼이건(Android, rinux, IOS 등...) URI를 통한 접근이 가능해야 한다.
-
Stateless
서버는 클라이언트의 상태를 알 필요가 없다. 즉, 세션유지를 하지 않는다.
-
Cacheable
REST는 기본적인 HTTP방식을 사용한다. 즉 기본적인 HTTP 통신의 캐시를 사용할 수 있다.
-
Client - Server 구조
클라이언트와 서버의 역할을 확실하게 나눠야 한다. 즉, 서버는 API만을 제공하며, 클라이언트는 로그인 정보, 세션 등의 관리가 잘 이루어져야 한다.
-
계층화(Layered System)
클라이언트는 보통 대상 서버에 직접 연결되었는지, 또는 중간 서버를 통해 연결되었는지를 알 수 없다.
클라이언트는 그냥 서버로부터 데이터만 받으면 되기 때문이다. 따라서 서버로 가는 경로에 로드밸런스나 공유 캐시 등을 넣어 시스템 규모의 확장을 유용하게 할 수 있다.
-
Code on demand(optional)
서버가 네트워크를 통해 클라이언트에 전달한 javascript 등과 같은 프로그램들은 그 자체로 실행이 될 수 있어야 한다. 이것은 사전 구현에 필요한 기능의 수를 줄임으로써 클라이언트를 단순화한다.
이 말은 우리가 평소에는 정적인 데이터를 xml 또는 json에 담아서 client로 보내고 client가 이것을 가공한다. 하지만 code on demand라는 것은 client에 보내는 데이터를 바로 실행 가능한 코드를 보내서 이것을 Client에서 실행하는 것을 말합니다.
-
-
규칙
-
모든 정보는 URI로 표현
어떤 메서드를 사용하던지 같은 데이터의 URI경로는 동일해야함
ex) GET school/class, POST school/class, DELETE school/class
-
계층관계를 표현할 땐 '/'를 사용
-
언더바( _ ) 을 사용하지 않고 하이픈( - ) 을 사용
언더바를 사용하는 경우 주소창에 문자가 가려지거나 사용자가 읽을 때 가독성이 떨어질 수 있기 때문
-
띄어쓰기X
-
URI의 표현은 소문자로
-
URI에 확장자를 표시하지 않음
-
URI의 표현은 동사가 아닌 명사로
ex) GET school/class //OK, GET school/study //Fail
-
URI 끝에 '/'를 붙이지 않음
ex) GET school/class //OK, GET school/class/ //Fail
-
참고자료
