일반적으로 알고있는 REST API
URI를 통해 자원을 지정하고
HTTP 매소드를 통해 자원에 대한 행위를 표현하는 것.
HTTP 매소드:
| CRUD | Method | URL |
|---|---|---|
| CREATE | POST | /user |
| READ | GET | /user/1 |
| UPDATE | PUT | /user/1 |
| DELETE | DELET | /user/1 |
Roy T. Fielding(REST개념 창시자)이 말하는 REST API
REST?
-> 리소스 상태(Resource State)의 표현(Representation)를 전송(Transfer)한다고 하여 REST(Representation State Transfer)라고 이름을 붙임.
-> REST API란 REST 아키텍쳐 스타일에 부합하는 API다.
REST 아키텍쳐 스타일에 부합하는 API 조건
1. Client-Server
- 웹은 HTTP라는 프로토콜을 이용해 클라이언트와 서버가 서로 통신하는 클라이언트/서버의 아키텍처 스타일을 채용하고 있다. 즉, 클라이언트가 서버에 요청(Request)을 보내면, 서버는 클라이언트에 대해 응대(Response)을 돌려준다.
2. Stateless
- 스테이트리스란, 클라이언트의 애플리케이션 상태를 서버에서 관리하지 않는다는 것을 의미한다.
서버가 애플리케이션의 상태를 가지지 않게 되면, 그만큼 서버 측의 구현을 간략화 할 수 있다.
HTTP를 스테이풀하게 만드는 대표적인 것은 Cookie를 사용한 세션 관리다.
(REST의 관점에서 본다면, Cookie를 사용한 세션 관리는 HTTP의 잘못된 확장이다. 다만, REST의 기준으로 잘못되었다고 해서, Cookie를 사용한 폼 인증을 그만둘 수 없다는 것도 현실이기에 Cookie는 스테이트리스 서버의 이점을 버린다는 것을 이해한 후에 최소한으로 이용한다.)
3. Cache
- 한번 가져온 리소스를 클라이언트 쪽에서 돌려쓸 수 있어야 한다.
4. Uniform Interface
- URI로 지정한 리소스에 대한 조작을 통일되고 한정적인 인터페이스로 수행하는 아키텍처 스타일을 말한다.
- URI를 통해 자원에 대한 식별이 가능해야 한다. ex) GET /user/1
- 표현을 통한 자원에 대한 조작 ex) 파일확장자 혹은 return 메시지 등
- 메시지는 스스로에 대해 설명해야 한다.
ex) host헤더의 도메인, 캐쉬 관련 헤더를 통한 캐쉬 전략 지정등 - 하이퍼미디어를 통한 앱 상태 변경(HATEOAS)
ex) 페이지 변경
URI를 통해 자원에 대한 식별(URI)
만약 숨겨진 페이지, 숨겨진 경로가 존재한다면 HATEOAS 위배
하이퍼미디어를 통한 앱 상태 변경(숨겨된 경로가 존재한다면 HATEOAS위배)
5. Layerd System
- 시스템을 몇 개의 계층으로 분리하는 아키텍처 스타일을 계층화 시스템이라고 한다.
- 웹 서비스에서는 서버와 클라이언트 간의 로드 밸런서를 설치해 부하를 분산시키거나, 프록시를 설치해 액세스를 제어한다. 클라이언트 측에서 보면, 서버나 프록시 모두 동일한 인터페이스로 접속할 수 있기 때문에 접속할 곳이 서버에서 프록시로 바뀐 것을 신경 쓸 필요가 없다.
- Code-On-Demand
- 프로그램 코드를 서버에서 다운받아 클라이언트에서 실행하는 아키텍처 스타일이다.
(클라이언트를 차후에 확장할 수 있음. JavaScript나 Flash, Java 애플릿 등이 해당.)
REST API는 무조건 사용해야 하는가?
-> NO, REST API는 스타일을 추가하고 제약을 부과하면서 발전했지만 상황에 따라 최적이 아닐 수도 있다. 그렇기에 GraphQL등 자신의 필요에따라 커스터마이징하여 사용해도 무관하다.
개구리