Rest API에 대해서 정리해보겠습니다.
우리가 흔히 알고 있는 Rest API를 과연 Rest API로 사용하고 있는지 알아보겠습니다.
모든 소스는 github에 올려두었습니다.
참조
www.youtube.com/watch?v=RP_f5dMoHFc
Rest API란?
Rest
REpresentational State Transfer
API
Application Programming Interface
먼저 Rest에 대해서 알아보겠습니다.
Rest의 풀네임을 해석하면 재현상 상태 전송 입니다.
좀 더 말을 풀어본다면 분산 하이퍼미디어 시스템을 위한 아키텍쳐 스타일입니다.
좀 더 쉽게한다면 웹을 위한 아키텍쳐 스타일입니다.
Rest를 구성하는 스타일
client-server
- Client Server 구조입니다.
- 자원이 있는 쪽이 Server, 요청을 하는 쪽이 Client입니다.
- Server : 비즈니스 로직이 있고 API를 제공하는 쪽입니다.
- Client : 사용자 인증이나 Context ( 세션 ) 등을 관리합니다.
stateless
- Client의 세션 정보 등 Context를 Server에 저장하지 않습니다.
- Server에 요청되는 API는 각각 별개인 것으로 간주된다. 이전 요청과는 상관없이 처리된다.
cache
- 캐시 처리 기능
uniform-interface
- Http protocal을 따르는 플랫폼은 모두 동작한다.
- URI로 지정된 Resource에 대한 조작이 통일된다.
layered system
- 계층화입니다.
- Client는 Rest API Server만 호출합니다.
- Server는 앞단에 로드벨런스, 암호, 인증 등을 사용하여 계층적으로 구성할 수 있습니다.
- Rest API Server는 로직을 실행합니다.
code on demand ( Optional )
- Client는 Server에서 스크립트를 받아 실행할 수 있습니다. ( ex. javascript )
Rest API란 무엇인가?
Rest API는 Rest를 구성하는 스타일을 갖춘 API 입니다.
그럼 우리들은 RestAPI를 Rest API 스타일에 맞게 사용하고 있을까요??
왜 아닐까요?
위 조건 대부분은 HTTP Protocol을 준수하는 플랫폼을 사용한다면 모두 충족시키는 것이 아닌가? 라고 생각할 수 있지만 uniform-interface 를 충족시키지 못하고 있습니다.
uniform-interface의 제약 조건
다음과 같은 4가지 제약 조건이 존재합니다.
identification of resources
- resource가 uri로 식별 가능해야한다.
manipulation of resources through representations
- representations를 통해서 resource 를 조작해야한다.
- update, create, delete 시 HTTP 메세지에 담아서 전송하여 resource 조작이 가능해야한다.
self descriptive messages
- 메세지가 스스로를 설명해야한다.
hypermedia as the engine of application status ( hateoas )
- application 상태는 hyperlink를 이용해 전이되어야 한다.
여기서 self descriptive messages, hypermedia as the engine of application status를 충족시키지 않고 Rest API라고 사용하고 있었습니다. 왜 충족시키지 못하는 지 알아보겠습니다.
self descriptive message
먼저 우리가 흔히 사용하는 Rest API URI를 살펴보겠습니다.
robot의 정보를 조회하는 URI입니다.
GET /api/robots이건 self descriptive를 충족하지 못하고 있습니다. 이유는 목적지 Host 정보가 빠져있습니다.
이번엔 self descriptive를 충족하도록 변경해보겠습니다.
GET /api/robots
HOST : www.robotmanager.com
위 Rest API로 요청하여 Response값을 확인해보도록 하겠습니다.
/api/robot 200 OK
[ { "op" : "remove", "path" : "/a/b/c" } ] 해당 Response는 self descriptive message를 충족하지 않습니다.
client가 server로부터 받은 값을 어떤 문법으로 작성되었는지 확인할 수 없어서 해석이 불가능하기 때문입니다. 수정해보겠습니다.
/api/robot 200 OK
Content-Type : application/json
[ { "op" : "remove", "path" : "/a/b/c" } ] 이렇게 수정하면 Client에서 [] {} 가 어떤 의미인지 해석이 가능합니다. 하지만 아직 self descriptive message는 아닙니다. 아직 Client는 op, path가 무엇을 의미하고 있는지 알 수 없기 때문입니다.
다시 수정해보겠습니다.
/api/robot 200 OK
Content-Type : application/json-patch+json
[ { "op" : "remove", "path" : "/a/b/c" } ] 이처럼 MediaType를 patch+json으로 지정해주면 Client는 patch+json 명세를 찾아가서 op, path가 무엇을 의미하는지 파악할 수 있게됩니다. 이로써 self descriptive message를 충족하게 되었습니다.
hypermedia as the engine of application status ( hateoas )
Application의 상태를 hyperlink를 통해서 전이할 수 있어야합니다.
Client에서 흔히 받는 Response값을 살펴보겠습니다.
<header>
Content-Type : application/json
<body>
{
"id": 1,
"name": "RobotV",
"age": 325
}이 response는 hateoas가 아닙니다. 여기서는 hyperlink를 통해 전이할 수도 없을 뿐더러 hyperlink 자체가 없습니다.
수정해보겠습니다.
<header>
Content-Type : application/hal+json
<body>
{
"id": 1,
"name": "RobotV",
"age": 325,
"_links":{
"self":{
"href": "http://localhost:8084/api/robots/1"
},
"create":{
"href": "http://localhost:8084/api/robots"
}
}
}Response를 이런식으로 받으면 Content-Type이 hal+json 타입인지 인지할 수 있고 Body에 Hyperlink가 존재하기 때문에 상태전이도 가능합니다.
이렇게 사용하면 우리는 RestAPI라고 당당히 말할 수 있습니다.
여태까지 우리가 Rest API라고 알고 사용했던 API는 Http API일 것입니다!
다음 정리할 내용은 Spring boot에서 Hateoas를 적용하여 위와같은 response를 얻는 RestAPI를 생성해보겠습니다.
'Study > spring' 카테고리의 다른 글
| @Autowired vs @Inject vs @Resource (4) | 2021.02.18 |
|---|---|
| [Hateoas] Rest API를 구현해보자 (0) | 2020.12.17 |
| Spring Triangle [IoC, AOP, PSA] - 3탄 PSA편 (0) | 2020.12.15 |
| Spring Triangle [IoC, AOP, PSA] - 2탄 AOP편 (0) | 2020.12.14 |
| Spring Triangle [IoC, AOP, PSA] - 1편 IOC편 (0) | 2020.12.13 |