REST (REpresentational State Transfer)

사람인과 잡코리아에서 회사 지원하려고 보는데 우대사항에 거의 80%이상 기재되어 있는 REST / RESTful / REST API ...

도대체 REST가 무엇이길래 대부분의 회사에서 사용하는 건지 궁금해서 공부해봄

 

REST (REpresentational State Transfer)

: 분산 하이퍼미디어 시스템(예: 웹)을 위한 아키텍쳐 스타일(제약조건 집합)

 

REST API 

: REST 아키텍쳐 스타일을 따르는 API

- REST 모습(이름)만으로도 추론 가능하고 상태정보를 주고 받음 (Create, Read, Update, Delete)

 

RESTful

: REST API를 제공하는 웹 서비스 (REST 원리를 따르는 시스템)

 

* REST 주요 목표

- 구성 요소 상호작용의 규모 확장성

- 인터페이스의 범용성

- 구성 요소의 독립적인 배포

- 중간적 구성요소를 이용해 응답 지연 감소, 보안을 강화, 레거시 시스템을 인캡슐레이션

 

* REST 아키텍쳐에 적용되는 6가지 제한 조건

1. client-server 클라이언트-서버 구조

: 아키텍쳐를 단순화시키고 작은 단위로 분리(decouple)함으로써 클라이언트-서버의 각 파트가 독립적으로 개선될 수 있도록 해줌

2. stateless 무상태

: 각 요청 간 클라이언트의 콘텍스트가 서버에 지장되어서는 안됨

3. cacheable 캐시 처리 가능

: www에서와 같이 클라이언트는 응답을 캐싱할 수 있어야 함

4. uniform unterface 인터페이스 일관성

: 독립적 진화를 위해 일관적인 인터페이스로 분리되어야 함 (서버의 기능이 변경되어도 클라이언트를 업데이트할 필요 없음)

- identification of resources URI로 리소스가 식별

- manipulation of resources through representations 리소스를 만들거나 삭제, 수정할 때  http 메시지에 그 표현을 전송

- self-descriptive message 메시지는 스스로를 설명해야 함

 . 확장 가능한 커뮤니케이션

 .. 서버나 클라이언트가 변경되더라도 오고가는 메시지는 언제나 self-descriptive하므로 언제나 해석 가능함

- hypermedia as the engine of application state(HATEOAS) 애플리케이션의 상태는 hyperlink를 이용해 전이되어야 함

 . 애플리케이션 상태 전이의 late binding

 .. 링크 동적 변경될 수 있음

 ==> 붉은 글씨 두 가지는 잘 지켜지지 않고 있으나, REST를 따르려면 self-descriptive와 HATEOAS를 만족시켜야 함

 → self-descriptive는 custom media type, profile link relation으로 만족 가능

 → HATEOAS는 http 헤더나 본문에 링크를 담아 만족 가능

5. layered system 계층화

: 클라이언트는 보통 대상 서버에 직접 연결되었는지, 또는 중간 서버를 통해 연결 되었는지를 알 수 없음. 중간 서버는 로드 밸런싱 기능이나 공유 캐시 기능을 제공함으로써 시스템 규모 확장성을 향샹시키는데 유용함

6. code on demand (optional) 

: 자바 애플릿이나 자바스크립트의 제공을 통해 서버가 클라이언트가 실행시킬 수 있는 로직을 전송하여 기능을 확장시킬 수 있음

 

 

참고 영상 : https://www.youtube.com/watch?v=RP_f5dMoHFc

 

참고 링크1 : https://hahahoho5915.tistory.com/54

[간단정리] REST, REST API, RESTful 특징

참고 링크2 : https://ko.wikipedia.org/wiki/REST

REST - 위키백과, 우리 모두의 백과사전

 

---

나의 프로젝트는 그래도 나름 REST를 지켰나? 생각해보았는데 전혀 지키질 못한 거 같다;;

예를 들어서 게시글 조회를 GET방식으로 board / 게시글 삭제를 DELETE방식으로 board라고 했어야 하는데

GET방식으로 getBoard / DELETE방식으로 deleteBoard 이렇게 uri를 지정했었다..!!!

다음번 프로젝트 때는 이 부분을 좀 더 신경써서 REST방식에 한 발짝 다가가야겠당!!!!

 

그리고 구글링 해보니 필딩 선생님은 REST가 아닌 API를 REST API라고 불리는 것을 거의 극혐하시나보다,,..

모든 사람들이 다 저 부분을 얘기하길래 도대체 얼마나 싫어하시길래..하는 궁금증이 생겼다..,;;;

 

아무튼 이렇게 세가지 방법이 있어서 알아서 선택해서 부르면 될거같다~~~

1. REST API를 구현하고 REST API라고 부르기

2. REST API를 포기하고 HTTP API라고 부르기

3. REST API가 아니지만 REST API라고 부르기 (REST 저자 필딩이 싫어한다고 함)

 

 

필딩 선생님이 말씀하시길

시스템 전체를 통제할 수 있다고 생각하거나, 진화에 관심이 없다면 REST 에 대해 따지느라 시간을 낭비하지 마라.

고 하셨다. 나는 REST에 너무 얽매여 있지 말고 개발 공부나 더 해야 겠다..^___^...