REST, REST API, RESTful 과 HATEOAS

더이상 미룰 수 없다. 너의 결혼, 나의 Rest API와 Hateoas 정리 ㅋ_ㅋ

 

Rest, Restful 참 많이도 들어봤다. 도대체 Rest API는 무엇인가?

결론적으로 얘기하면 REST는 아키텍쳐이고, REST API는 REST를 기반으로 서비스 API를 구현 한 것이다.

 

REST

Rest란?

먼저 REST는, 자원 기반의 구조(ROA, Resource Oriented Architecture)설계에서

그 중심에 Resource가 있고 이 Resource 를 처리 하기 위해서 HTTP Method를 활용하는 아키텍쳐이다.

REST에서 가장 중요한 것은 Resource이다. 이렇게 중요한 자원을 REST에서는 서버와 클라이언트간에 어떻게 주고 받느냔 말이다?

그 답은 바로 REST 안에 있다. REST stands for Representational State Transfer인데 자원의 '상태'를 전송할 건데, 이 상태의 전송을 Representational 하게 하겠다는 말이다. 자원을 Representational하게 표현하겠다는 것은 자원의 '이름'으로 표현한다는 것이고,

자원의 어느시점의 '상태'를 전송하냐면 '데이터가 요청되어지는 시점'에의 자원의 상태를 전송한다.

이러한 자원을 Transfer 할 때는 모든 자원에 고유한 ID인 HTTP URL을 부여한다.

 

이러한 REST 아키텍쳐는 기존의 웹기술과 HTTP 프로토콜의 인프라를 그대로 사용하기 때문에 웹의 장점을 최대한 활용할 수 있다. 하지만 구형 브라우저에서는 PUT, DELETE같은 HTTP Method는 아직 사용할 수 없다.

 

Rest의 구성요소

자원 (Resource ) : URI

• 모든 자원에 고유한 ID가 존재하고, 이 자원은 서버에 존재한다.
• 자원은 HTTP URI로 구별한다.
• client는 자원의 상태에 대한 조작을 요청한다.

행위 (verb)

• 행위는 HTTP 메소드를 사용한다(GET, POST, PUT, DELETE).

표현 ( Representation Of Resource)

• client가 자원의 상태에 대한 조작을 요청하면, 서버는 이에 대한 응답(Representation)을 보낸다.
• Rest에서 하나의 자원은 여러 형태의 Representation으로 나타내어질 수 있다.

 

Rest의 특징

서버-클라이언트 구조

• 자원이 있는쪽이 Server, 자원을 요청하는 쪽이 Client가 된다.

Stateless(무상태)

• HTTP 프로토콜의 인프라를 그대로 사용하기 때문에 Rest 역시 Stateless의 특징을 가진다.
• 클라이언트의 context(세션, 쿠키 등)를 서버에 저장하지 않는다.
• 각각의 요청을 완전히 별개의 것으로 인식하고 처리한다.

캐시 처리 가능

• HTTP 가 제공하는 캐싱 기능을 사용하여 응답을 캐싱할 수 있다.

Layered System(계층화)

• 클라이언트는 Rest API Server만 호출하지만 서버는 다중 계층으로 구성될 수 있고 클라이언트는 서버에 직접 연결되었는지, 
  미들웨어에 연결되었는지 알 필요가 없어야 한다.
• 확장성, 보안성을 위해 로드밸런싱, 공유 캐시 사용 가능
• 보안, 로드밸런싱, 암포화, 사용자 인증 등을 비즈니스 로직 수행 전에 수행

Code - On -Demand(Optional)

• Server로 부터 스크립트를 받아서 Client에서 실행한다.

Uniform Interface(인터페이스 일관성)

• URI로 지정한 자원에 대한 조작을 통일되고 한정적인 인터페이스로 수행한다.
• HTTP 표준 프로토콜을 사용하는 모든 플랫폼에서 사용 가능하다.

 

 

REST API

이제 restAPI에 대해 알아보자. REST 를 사용하기 위한 Application Program Interface겠지뭐.

 

REST API 설계 규칙

URI로 자원을 표현할 때

• 동사보다는 명사를, 대문자보다는 소문자를 사용한다.
• 도큐먼트이름은 단수 명사를( ex.GET /Student/1) , 컬렉션이나 스토어의 이름으로는 복수명사를 사용한다.( ex.GET /students/1 )

자원의 행위를 표현할 때

• HTTP Method로 표현한다. ( ex.GET /members/1 , DELETE /members/1 )
• URI에는 HTTP Method나 동사 표현이 들어가면 안된다 ( ex. GET /members/show/1, POST /members/post/1 )

기타

• 슬래시 구분자는 계층 관계를 나타낸다.
• URI의 마지막 문자는 슬래시를 포함하지 않는다.
• 언더바(_) 대신 하이픈(-)을 사용하여 가독성을 높인다.
• 소문자를 사용한다.
• 파일 확장자는 Accept Header를 사용한다.
  http://restapi.example.com/members/soccer/345/photo.jpg (X)
  GET /members/soccer/345/photo HTTP/1.1 HOST:restapi.example.com Accept:image/jpg (O)
• 리소스간에 연관관계가 있는 경우
  GET : /users/{userid}/devices

출처 ( https://gmlwjd9405.github.io/2018/09/21/rest-and-restful.html )

 

 

 

RESTFUL

시스템이 Restful하다고 말할 수 있으려면, REST의 특징인 서버-클라이언트구조, stateless, cacheable, Layered System, code on demend, uniform Interface의 특징을 전부 가지고 있어야 한다. 그중 서버-클라이언트 구조, 무상태, 캐시, 계층화, code-on-demand는 HTTP에서 이미 충분히 지켜지고 있는 부분이다. 그렇기 때문에 Uniform interface의 특징이 REST에서는 중요하겠다.

uniform interface의 특징을 지키기 위해서는

• 자원은 유일하게 식별 가능하게 하고
• HTTP Method로 표현을 담아야 하고 
• 메세지는 스스로를 설명해야하고(self-descriptive)
• 하이퍼링크를 통해 애플리케이션의 상태가 전이(HATEOAS)

되어야 한다.

(https://jeong-pro.tistory.com/180)

 

 

HATEOAS

HATEOAS 는 Hypermedia as the engine of Application State를 뜻하는 용어로 애플리케이션의 상태를 나타내는 엔진으로 Hypermedia 즉, '링크'를 사용하겠다는 것이다. Client가 API를 요청하고 서버가 이에 대한 요청을 줄 때, 요청에 대한 응답 뿐만 아니라 요청 이후 client가 다음에 요청할 요청들에 대한 URI까지 함께 return 해주는 것이다. 이러한 URI를 통해서 클라이언트는 애플리케이션의 상태를 다음 요청으로 전이시킬 수 있게 되는 것이다. 

 

이러한 HyperMedia를 포함한 응답은 HAL(Hypertext Application Launguage)를 사용하여 JSON이나 XML 형식으로 만들 수 있다.HAL은 아래와 같이 두가지로 응답 데이터 타입을 갖는다.

• application/hal+json
• application/hal_xml

https://wonit.tistory.com/454

 

 

Spring에서 HATEOAS를 적용하는 방법은 아래 링크를 참조하자

https://bamdule.tistory.com/247

[SpringBoot] HATEOAS 적용하기