REST ?
HTTP/1.0과 1.1의 스펙 작성에 참여하고 아파치 HTTP 서버프로젝트의 공동 설립자인 로이 필딩의 논문에 처음 소개되었으며, HTTP의 장점을 최대한 활용할 수 있는 아키텍처
API ?
Application Programming Interface(애플리케이션 프로그램 인터페이스)의 줄임말
Application : 고유한 기능을 가진 모든 소프트웨어
Interface : 두 애플리케이션 간의 서비스 계약
요청(Request)과 응답(Response)을 사용하여 두 애플리케이션이 서로 통신하는 방법
- API 문서에는 개발자가 이러한 요청과 응답을 구성하는 방법에 대한 정보가 들어 있다.
구글 REST API 가이드문서
REST API 란?
REST를 기반으로 서비스 API를 구현한 것
HTTP를 이용해서 기계들이 통신을 할 때 HTTP가 가지고 있는 기능을 최대한 활용해서 명확하면서 단순하게 통신할 수 없을까?하는 고민에서 출발한 모범사례
특징
- 인터넷 식별자(
URI)와HTTP프로토콜을 기반으로 한다. - REST는 HTTP 프로토콜 덕분에
‘단순함’이 핵심이라고 할 수 있다.
각 요청이 어떤 동작이나 정보를 위한 것인지를 그 요청의 모습 자체로추론 가능하다는 것이 큰 특징이다.(a.k.a 자체 표현구조) - 데이터 포맷으로는 브라우저 간 호환성이 좋은
제이슨(JSON)을 사용 - 과거에 SOAP 이라는 복잡한 형식을 대체하고있음.
SOAP API?
SOAP(Simple Object Access Protocol)는 그 자체로 프로토콜이며, 보안이나 메시지 전송 등에 있어서 REST보다 더 많은 표준들이 정해져있기 때문에 조금 더 복잡하다.
BUT!
보안, 트랜잭션, ACID(원자성, 일관성, 고립성, 지속성)을 준수해야 하는 보다 종합적인 기능이 필요한 조직에게는 적합한 방식이 될 수 있다. 굳이 비교를 하자면, SOAP는 웹 서비스 시나리오에 적용하기에는 그다지 좋지 않기 때문에, 기업용 애플리케이션 등을 작업하는데 더 이상적이라고 할 수 있다.
TMI
- REST는 웹에 최적화되어 있고, 데이터 포맷이 JSON이기 때문에 브라우저들 간에 호환성이 좋으며 그
성능과 확장성이 뛰어난 것으로도 알려져 있다.
하지만 다른 기술들과 마찬가지로 그 자체의 기능이 정지되거나 여러분의 앱을 먹통으로 만들 수도 있다. ex) REST API 단점 3가지
그래서 REST로는 풀지 못하는 문제들을 해결하기 위해서 그래프 QL 과 같은 언어가 생겨났다.
REST의 기본 원칙을 성실히 지킨 서비스 디자인을 "RESTful"이라고 표현한다.
구성
REST는 자체 표현구조(보이는 그대로 표현된 구조)로 구성되어있어 REST API만으로 HTTP 요청의 내용을 이해할 수 있다.
3가지 요소로 구성되어있다.
자원(resource)
URI 로 표현해야한다
// 예시
GET /todos/1
// bad
GET /getTodos/1 //getTodos x
GET /todos/show/1 //show x리소스를 식별할 수 있는 이름은 동사보다는 명사를 사용한다.
get과 같은 행위에 대한 표현은 안된다.
행위(verb)
HTTP 요청 METHOD(메서드)로 표현한다.
HTTP 요청 METHOD(메서드)
클라이언트가 서버에게 요청의 종류와 목적(리소스에 대한 행위)을 알리는 방법
CRUD 를 사용한다!
리소스에 대한 행위는 메서도를 통해서만 표현하며, URI에 표현하지 않는다.
표현(representations)
리소스에 대한 메서드의 구체적인 내용(내용물: 페이로드)
body 부분
REST API를 디자인하는 방법
로이 필딩이 논문에서 제시한 REST방법론을 보다 더 실용적으로 적용하기 위해 만들어진 성숙도 모델이 있으며 총 4단계로 나누어진다.
실제로 3단계까지 지키기 어렵기 때문에 2단계까지만 적용해도 좋은 (RESTful한) API 디자인이라고 볼 수 있고, 이런 경우를 HTTP API 라고도 부른다.
REST 성숙도 모델 0단계
- 단순히 HTTP 프로토콜을 사용하기만 해도 된다.
- 하지만 이러한 API는 REST API라고 할 수 없으며, 0단계는 REST API를 작성하기 위한 기본단계이다.
REST 성숙도 모델 1단계
- 개별 리소스(Resource)와의 통신을 준수해야한다.
- 모든 자원은 개별 리소스에 맞는 엔드포인트(Endpoint)를 사용해야한다.
- 요청하고 받는 자원에 대한 정보를 응답으로 전달해야한다.
엔드포인트작성 시 동사, HTTP 메서드, 혹은 어떤 행위에 대한 단어 사용은 지양하고,
리소스에 집중하여명사형태의 단어로 작성하는 것이 바람직하다. ⇒구성 - 자원 설명에 포함된 부분요청에 따른 응답으로 리소스를 전달할 때에도 사용한 리소스에 대한 정보와 함께 리소스 사용에 대한
성공/실패여부를반환해야한다.
REST 성숙도 모델 2단계
CRUD에 맞게 적절한HTTP 메서드를 사용하는 것에 중점을 둔다. ⇒구성 - 행위 설명에 포함된 부분
HTTP 메서드 사용 규칙
GET서버의 데이터를 변화시키지 않는 요청에 사용한다. (리소스취득) (페이로드 X)POST요청마다새로운 리소스를 생성한다.PUT요청마다같은 리소스를 반환(멱등'idempotent')하며 리소스를전체교체할 때 사용한다.PATCH리소스의 일부를 수정할 때 사용한다.DELETE모든/특정 리소스를삭제할 때 사용한다.(페이로드 X)
REST 성숙도 모델 3단계
- HATEOAS(Hypermedia As The Engine Of Application State)라는 약어로 표현되는
하이퍼미디어 컨트롤을 적용한다. 응답에는 리소스의URI를 포함한링크 요소를 삽입하여 작성해야한다.
Open API
- 누구나 쉽게 접근할 수 있도록 열려있는 API
- API 마다 정해진 이용수칙이 있고, 그 수칙에 따라 제한사항이 있을 수 있다.
API Key
- 서버의 문을 여는 열쇠
- API Key가 필요한 경우에는 로그인한 이용자에게 자원에 접근할 수 있는 권한을 API Key의 형태로 제공하고,
데이터를 요청할 때 API Key를 같이 전달해야 원하는 응답을 받을 수 있다.
