Portfolio

REST Architecture를 따르는 API

참고

[글] Q&A | MVC and RESTful API service의 관계에 대하여

[영상] 토스 | SLASH 21 - 결제 시스템의 SDK와 API 디자인

REST(Representational State Transfer : 자원의 상태 전달) - 네트워크 아키텍처 인터페이스 일관성에 대한 추가 설명 Level 0 Level1 Representations Level 2 : Http 메서드를 도입하는 것 Level 3 HATEOAS API 인터페이스 일관성의 제약조건 1. 자원의 식별(Level 1)2. 메시지를 통한 리소스 조작(Level 1)3. 자기 서술적 메시지(Level 2)자기서술적 메시지를 지키기 위한 방법1. Media Type 명시 4. Application 상태에 대한 엔진으로써 하이퍼미디어(HATEOS)Uniform interface는 왜 필요한가?REST API 꼭 다 지켜야하나??

REST(Representational State Transfer : 자원의 상태 전달) - 네트워크 아키텍처

분산 하이퍼미디어 시스템(예 : 웹)을 위한 아키텍처 스타일(= 제약 조건의 집합)

간단한 의미로는, 웹 상의 자료를 HTTP위에서 SOAP이나 쿠키를 통한 세션 트랙킹 같은 별도의 전송 계층 없이 전송하기 위한 아주 간단한 인터페이스 말함

한마디로, HTTP의 메서드의 의미를 정확히 사용을 해서 리소스를 컨트롤하자 → Resource를 생성하려면 Post/Put으로 하자, Resource를 읽으려면 GET을 쓰자, Resource를 변경하려면 PUT을 쓰자, Resource를 제거하려면 DELETE를 쓰자.

아래 1,2,3,4는 HTTP만 사용해도 충족하는 특성임. 5번이 중요

Client, Server: 클라이언트와 서버가 서로 독립적으로 분리 되어 있어야 함

Stateless : 요청에 대해서 클라이언트의 상태를 서버에 저장하지 않음(매 요청마다 새로운 것임)

Cache : 클라이언트는 서버의 응답을 Cache(임시저장)할 수 있어야 함. 클라이언트가 Cache를 통해서 응답을 재사용할 수 있어야 하며, 이를 통해 서버의 부하를 낮춤

계층화(Layered System) : 서버와 클라이언트 사이에, 방화벽, 게이트웨이, Proxy 등 다양한 계층 형태로 구성이 가능해야 하며, 이를 확장 할 수 있어야함

인터페이스 일관성 : 인터페이스의 일관성을 지키고, 아키텍처를 단순화시켜 작은 단위로 분리하여, 클라이언트, 서버가 독립적으로 개선 될 수 있어야함

https://martinfowler.com/articles/richardsonMaturityModel.html (Richardson 성숙도 모델)

Code On Demand(Optional) : 자바애플릿, 자바스크립트, 플래시 등 특정한 기능을 서버로부터 클라이언트가 전달받아 코드를 실행 할 수 있어야 함

인터페이스 일관성에 대한 추가 설명

Level 0

Remote Procedure Call : 외부에서 메서드를 호출하는 것. url이 단 하나. 거기에 요청을 xml로 정의, post로 호출. xml에 자료를 받기 원한다. 어떤 메서드를 호출할거다, 어떤 명령을 전달한다 등의 내용을 xml로 기술하고 전달

서버가 그것을 보고 응답을 xml로 줌 → REST가 아님. 모든 Resource에 대한 정의가 아예 안되어 있는 것

Level1

Resource 단위로 엔드포인트가 생기는 것

고객 - kdt/customers
주문 - kdt/orders

Representations

어떠한 리소스의 특정 시점의 상태를 반영하고 있는 정보이고 representation data와 representation metadata로 구성됨

representation data가 hello인데 representation metadata에 따라 표현이 달리 되는 것

Level 2 : Http 메서드를 도입하는 것

get, put, post, delete

resource에 접근하는 용도에 맞게 get, put, post, delete 를 적절히 사용하면 Level2 까지 올라온 것

Level 3

HATEOAS

Hypermedia(연결된 미디어. 초월적 미디어). 모든 리소스의 연결성을 가져감

리소스를 받으면 그 리소스를 가지고 할 수 있는 행위들을 기록하는 것. links에 보면 action이 기록되어 있는 것 → 이걸 지원하면 Hypermedia Control을 지원하는 것임

그러나 일반적으로 서비스 개발 시에는 거의 쓰지를 않음

[참고] https://spring.io/projects/spring-hateoas


{
"id": "1",
"contents": "공부합시다.",
"createAt": "2020-01-01 12",
"likes": 2,
"likesOfMe": false,
"comments": [],
"writer": { "id": "2", "email": "harry@gmail.com", "name": "harry" },
"links": [
{"rel": "self", "action": "GET", "href": "/api/v1/posts/1"},
{"rel": "deletePost", "action": "DELETE", "href": "/api/v1/posts/1" },
{"rel": "getWriter", "action": "GET", "href": "/api/v1/users/1" },
{"rel": "addComment", "action": "POST", "href": "/api/v1/posts/1/comments"}

API

API is a set of subroutine definitions, protocols, and tools for building application software. In general terms, it is a set of clearly defined methods of communication between various software components.

커뮤니케이션을 하기 위해 필요한 게 프로토콜인데, 이게 REST로 정의된게 REST API임

REST API : REST 아키텍처 스타일을 따르는 API

인터페이스 일관성의 제약조건

1. 자원의 식별(Level 1)

Uri에 자원을 식별할 수 있는 정보가 담겨있어야함

https://foo.co.kr/user/100

Resource : user
식별자 : 100

2. 메시지를 통한 리소스 조작(Level 1)

데이터 전달 방법 : HTML, XML, JSON, TEXT

Http header 부분에 content-type을 통해서 데이터의 타입을 지정해 줄 수 있음

또한 리소스 조작을 위해 데이터 전체 전달이 아닌 메시지로 전달을 함

Eg) 서버의 user라는 정보의 전화번호를 처음에는 number로 결정 후, Client와주고 받을 때 그대로 사용한다면 서버 resource를 phone-number로 바뀌게 되면 Client는 처리하지 못하고 에러가 남 ⇒ 별도의 메시지 형태로 데이터를 주고 받아야 함