REST

ordilov / 2022. 1. 7

Representational State Transfer의 약자입니다.
REST는 네트워크에서 전송을 위한 아키텍처입니다.
이름에서 보듯이 표현할 수 있는 상태를 주고 받을 수 있어야 합니다.
데이터를 주고 받을 수 있는 방법은 많은데 왜 REST를 준수할까요?

REST가 왜 필요한지 알려면 왜 만들어졌는지를 먼저 알아야 합니다.
HTTP를 설계한 로이 필딩이 HTTP의 하위호환성을 안 깨트리면서 발전시키기 위해 만들었습니다.
즉 중요한 점은 하위 호환성이었습니다.
앞으로 서버에서 업데이트가 있더라도 클라이언트는 그대로 사용할 수 있어야 했습니다.
그러기 위해서 지켜야하는 규칙들이 아키텍처입니다.

인터페이스 일관성

일관적인 인터페이스로 분리되어야 합니다

무상태(Stateless)

각 요청 간 클라이언트의 콘텍스트가 서버에 저장되어서는 안 됩니다.

캐시 처리 가능(Cacheable)

WWW에서와 같이 클라이언트는 응답을 캐싱할 수 있어야 합니다.

계층화(Layered System)

프록시 서버처럼 중간에 거치는 서버가 더 있더라도 사용할 수 있어야합니다.

Code on demand (optional)

javascript처럼 실행할 수 있는 로직을 코드로 전달할 수 있어야합니다.

클라이언트/서버 구조

클라이언트와 서버가 독립적으로 업데이트할 수 있어야 합니다.

요청 내에 기술된 개별 자원을 식별할 수 있어야 합니다.
웹 기반의 REST 시스템에서의 URI의 사용을 예로 들 수 있습니다.
데이터를 주고 받을 때도 우리는 정해진 형식으로 데이터를 주고 받습니다.
HTML, JSON 처럼 지정된 형식으로 데이터를 주고 받아야 합니다.

GET, POST 같은 메소드와 리소스만으로 서버의 리소스를 조작할 수 있어야 합니다.

각 메시지는 자신을 어떻게 처리해야 하는지에 대한 충분한 정보를 포함해야 합니다.
미디어 타입만 가지고도, 클라이언트는 어떻게 그 내용을 처리해야할 지 알 수 있어야 합니다.
메시지를 이해하기 위해 그 내용까지 살펴봐야 한다면, 그 메시지는 자기서술적이 아닙니다.
따라서 json, xml등 형식만 제공하는 것 외에도 어떻게 해석할지 정보가 필요합니다.

Hypermedia as the Engine of Application State의 약자입니다.
만약에 클라이언트가 관련된 리소스에 접근하기를 원한다면, 하이퍼미디어로써 정보를 지원해야합니다.
리소스에 대한 값 이외에도 리소스가 있는 위치 혹은 링크를 포함해 만족할 수 있습니다.

아키텍처들은 대부분 어떤 제약을 통해서 변화에 유연한 구조를 만들려고 합니다.
REST도 위의 제약들을 지키면 서버와 클라이언트가 독립적으로 변할 수 있습니다.