3_[spring]restful_api
REST API
❓ REST 규약 ❓
Representational State Transfer
“자원의 상태 전달”
- 웹에 존재하는 모든 자원에 고유한 URI 를 부여하여 활용
- 네트워크 아키텍쳐
- 아래의 6가지를 꼭! 지켜야 함
- Client & Server- 클라이언트와 서버가 서로 독립적으로 분리
- Stateless - 요청에 대해서 클라이언트의 상태를 서버에 저장x
- Cache - 클라이언트는 서버의 응답을 Cache(임시저장)할 수 있어야 하고, 이를 통해서 응답을 재사용할 수 있도록 함으로써 서버의 부하를 낮춘다
- 요즘에는 서버에서도 일부 캐시 관리를 하기도 함
- 계층화(Layered System) - 서버와 클라이언트 사이에는 방화벽, 게이트웨이, proxy 등 다양한 계층 형태의 구성이 가능해야 하고, 이를 확장시킬 수 있어야 한다
- 인터페이스 일관성 - 인터페이스의 일관성을 지키고, 아키텍쳐를 단순화시켜 작은 단위로 분리하여 클라이언트와 서버가 독립적으로 개선될 수 있도록 해야 한다[서버가 바뀐다고 클라이언트에 지장이 없어야 하고, 클라이언트측 사항이 바뀌어도 서버에 지장이 없어야 함]
- Code on Demand(선택사항) - 자바 애플릿 , 자바스크랩트, 플래시 등 특정 기능을 클라이언트가 서버로부터 전달받아 코드를 실행할 수 있어야 한다!
📌 REST API 제약조건 중 인터페이스 일관성이 잘 지켜졌는지 확인할 수 있는 방법
- 자원의 식별 - URI
예) 100번째 사용자 URI —> https://foo.co.kr/user/100
리소스 : user 식별자 : 100
- 메시지를 통한 리소스 조작
- 웹에서 데이터를 전달할 수 있는 방식 - HTML, XML, JSON, TEXT 등등
- 웹에서는 content-type헤더에 (HTTP Header 부분의 content-type) 데이터 타입을 지정해줌으로써 어떤 타입의 데이터를 전달할 것인지를 알려줄 수 있음 (jsp, servlet— request.setContentType(“text/html;charset=UTF-8”);)
- 웹에서는 리소스 조작을 위해서 데이터 전체를 전달하지 않고 메시지로 전달
(예) BEFORE : 서버의 사용자 user, user의 전화번호는 number로 클라이언트와 값을 주고 받았음
AFTER : user의 전화번호를 phone-number로 서버측에서 변경하게 되면 클라이언트는 처리를 하지 못하고 에러가 발생
💐 jsp 서블릿에서 ${user.myId}를 ${user.id}로 변경하는 상황과 유사한 상황!
▶️ 이를 방지하기 위해서 별도의 메시지 형태로 데이터를 주고 받으며 클라이언트와 서버가 독립적으로 확장가능하도록 함[▶️ REST 규칙 중 클라이언트와 서버의 독립성을 지키지 못한것!]
- 자기 서술적 메시지
- 요청하는 데이터가 어떻게 처리되어야 하는지 충분한 데이터를 포함시킬 수 있도록 명시
🌟 HTTP 기반의 REST에서는 HTTP Method와 헤더 정보(html이라는 점 등), URI에 포함되는 정보로 표현 가능
- GET : https://foo.co.kr/user/100 , 사용자의 정보 요청/조회 SELECT
- POST : https://foo.co.kr/user , 사용자의 정보 생성 CREATE
- PUT : https://foo.co.kr/user , 사용자 정보 생성 및 수정 UPDATE
- DELETE : https://foo.co.kr/user/100 , 사용자 정보 삭제 DELETE
그 외에 담지 못한 정보는 URI의 메시지를 이용하여 표현
- 어플리케이션 상태에 대한 엔진으로써 하이퍼미디어
- 단순 클라이언트 요청에 대한 데이터 응답뿐 아니라, 관련 리소스에 대한 링크도 같이 포함되어야 함
- 이 부분은 실제로는 잘 작성하지 않음- 불필요한 데이터도 넘어갈 수 있기 때문
이러한 일관성이 잘 갖춰진 경우를 “REST Ful“하다고 하며, 이를 REST API라고 부름!