[REST] REST API에 대한 고찰.

○ REST 기본 개념

REST는 SOAP API 이 후, 각광받는 API이다. REST는 어떠한 Interface 포맷을 의미하는데, 보통은 GET, POST, DELETE, PUT 그리고 PATCH를 사용하여 페이지 간 네트워킹을 하는 데에 돕는 API를 뜻한다.

이렇게 분류되어 있는 이유는 기술적인 차이보다는 개발자 간의 규약이라 보는 것이 좋다. 개발자의 상호작용을 효율성 있게 하기 위하여 이러한 포맷으로 분류한다.

 

○ REST 심화

REST는 정확하게 이야기 하면 아키텍쳐의 집합. 곧 제약조건의 집합이다. REST의 탄생 배경은 HTTP / 1.0에서 기존의 웹의 통신규약을 지키며 기능을 개선해야 하는 상황이었다. 그렇기에 REST API를 탄생시켰고 기존의 HTTP / 1.0 환경에서도 깨지지 않는 방안을 마련하였다. (REST의 계기 : How do I improve HTTP without breaking the Web. ─ architectural styles and the design of network-based software architectures 학술자료, 저자 로이 필딩)

그렇기에 REST의 핵심은 서버와 웹이 독립적이여야 하며, 독립적인 진화가 가능하여야 한다. 서버가 업데이트 된다 하더라도, 클라이언트에게 영향이 있으면 안된다는 의미이다.

이는 다음과 같은 네 가지의 제약 조건을 지켜야한다.

- identification of resources.(자원 식별)

- manipulation of resources through representations.(표현을 통한 자원 조작)

- self-descriptive messages.(자체 서명 메시지)

- hypermedia as the engine of application state(HATEOAS) (애플리케이션 상태의 엔진으로서의 하이퍼미디어)

대표적인 REST를 잘 지키고 있는 것은 브라우저를 볼 수 있다.

Fire fox / Explore / Chrome / Safari

- 웹페이지를 변경했다고 웹 브라우저를 업데이트 할 필요가 없다.

- 웹 브라우저를 업데이트했다고 웹 페이지를 변경할 필요도 없다.

- HTTP 명세가 변경되어도 웹은 잘 동작한다.

- HTML 명세가 변경되어도 웹은 잘 동작한다.

또한 대표적으로 제약을 잘 지키지 않는 경우는 앱을 예시로 들 수 있다. 서버에 대한 의존도가 적은 환경의 앱일 수록 업데이트가 필요하다면, 앱을 더욱 잦게 강제로 업데이트를 하여야 하며 서로에 대한 의존도가 높기에 독립적이기 힘들다.

이렇게 가능한 이유는 웹은 상호운용성이 아주 튼튼하기에 가능한 일이다. 이를 테면, charset은 흔히 쓰고 있는 태그이지만, 사실상 encoding이라는 의미에 가까운 의미를 갖고있다. HTTP는 이것을 encoding으로 수정하게 된다면, 상호운용성이 어긋날 수 있기에 고치지 않는다.

 

참고 사이트 및 논문

- architectural styles and the design of network-based software architectures 학술자료, 저자 로이 필딩

- 그런 rest api로 괜찮은가.

https://www.youtube.com/watch?v=RP_f5dMoHFc

- [PWA] 프로그레시브 웹 앱

https://geundung.dev/85?category=800492