REST (Representational State Transfer : 자원의 상태 전달) - 네트워크 아키텍처
1. Client, Server : 클라이언트와 서버가 서로 독립적으로 분리 되어 있어야 한다.
2. Stateless : 요청에 대해서 클라이언트의 상태를 서버에 저장하지 않는다.
3. Cache : 클라이언트는 서버의 응답을 Cache(임시저장) 할 수 있어야 한다.
4. 계층화 (Layerd System) : 서버와 클라이언트 사이에, 방화벽, 게이트웨이, Proxy server 등 다양한 계층 형태로 구성이
가능해야 하며, 이를 확장할 수 있어야 한다. 이를 통해서 서버의 확장을 이룰 수 있어야한다.
5. 인터페이스 일관성 : 인터페이스의 일관성을 지키고, 아키텍처를 단순화시켜 작은 단위로 분리하여, 클라이언트,
서버가 독립적으로 개선될 수 있어야 한다. 서버가 바뀌더라도 클라이언트에 지장이 없어야하고
클라이언트가 바뀌더라도 서버에 지장이 없어야 한다.
6. Code on Demand (Optional) : 자바 애플릿, 자바스크립트, 플래시 등 특정한 기능을 서버로부터 클라이언트가
전달받아 코드를 실행할 수 있어야 한다.
이 6가지를 잘지켰냐에 따라서 Restfull 하다, 아니하다 말하는 것이다.
다음의 인터페이스 일관성이 잘 지켜졌는지에 따라 REST를 잘 사용했는지 판단할 수 있다.
1. 자원의 식별
2. 메시지를 통한 리소스 조작
3. 자기 서술적 메시지
4. 애플리케이션 상태에 대한 엔진으로써 하이퍼미디어
① 자원의 식별
웹 기반의 REST 에서는 리소스 접근을 할 때 URI를 사용 합니다.
https://foo.co.kr/user/100 이러한 URI가 있다면 리소스에 대한 정보가 있어야한다
이때 리소스는 user이고 식별자가 100 이다.
②메시지를 통한 리소스 조작
Web에서는 다양한 방식으로 데이터를 전달할 수 있다.
그 중에서 가장많이 사용하는 방식은 HTML, XML, JSON, TEXT등 이 존재하며
이 중에서 어떠한 타입의 데이터인지를 알려주기 위해서 HTTP Header 부분에 content-type을 통해서 데이터의 타입을 지정해 줄 수 있다.
그리고 리소스 조작을 위해서 데이터 전체를 전달하지 않고, 이를 메시지로 전달한다.
ex) 서버의 user라는 DB가 있는데 어떤 테이블의 컬럼이 number라고 가정하자.
그리고 이 정보를 client와 주고받고 있었는데 후에 서버의 resource변경으로 phone-number라고 바꾸게 된다면
client는 처리하지 못하고 에러가 난다.
이러한 에러를 방지하기 위해서 별도의 메시지 형태로 데이터를 주고 받아야한다.
③자기서술적 메시지
요청 하는 데이터가 어떻게 처리 되어져야 하는지 충분한 데이터를 포함 할 수 있어야 한다.
HTTP 기반의 REST에서는 HTTP Method와 Header 정보, 그리고 URI의 포함되는 정보로 표현할 수 있어야한다.
④ Application 상태에 대한 엔진으로써 하이퍼미디어 REST API를 개발할 떄 단순히 Client 요청에 대한 데이터만 응답 해주는 것이 아닌 관련된 리소스에 대한 Link정보까지 같이 포함 되어져야 한다.
(4번째는 현업에서 잘 사용하지 않긴함)
위와 같은 조건들을 잘 갖춘 경우 REST Full 하다고 표현하고, 이를 REST API 라고 부른다.
'Spring' 카테고리의 다른 글
Spring - ObjectMapper (0) | 2022.01.11 |
---|---|
URI vs URL 개념정리 (0) | 2022.01.06 |
POJO의 특징 (0) | 2022.01.06 |
Failed to start bean 'documentationPluginsBootstrapper' (0) | 2022.01.05 |
Spring의 주요 특징 #제어의 역행, #의존성주입 (0) | 2022.01.04 |