Notice
Recent Posts
Recent Comments
Link
«   2024/07   »
일 월 화 수 목 금 토
1 2 3 4 5 6
7 8 9 10 11 12 13
14 15 16 17 18 19 20
21 22 23 24 25 26 27
28 29 30 31
Tags more
Archives
Today
Total
관리 메뉴

개발자일기

진정한 Rest Api란 무엇인가? 본문

개발

진정한 Rest Api란 무엇인가?

ka0oll 2020. 3. 28. 23:13

https://www.youtube.com/watch?v=RP_f5dMoHFc 의 영상을 토대로 정리함.

WEB의 등장

Q : 어떻게 인터넷에서 정보를 공유할 것인가?
A : 정보들을 하이퍼텍스트로 연결한다.
표현형식 : HTML, 식별자 : URI, 전송방법 HTTP

HTML : (HyperText Markup Language)
하이퍼텍스트 : 문서 내부에 다른 문서로 연결되는 참조를 집어 넣음으로서 서로참조할수있도록한다.

https://restfulapi.net/

REST

Rest는 웹의 창시자(HTTP) 중의 한 사람인 Roy Fielding의 2000년 논문에 의해서 소개되었다.

HTTP/1.0 (1994 - 1996)
로이필딩은 생각했다. "How do I improve HTTP without breaking the Web?"

-> 웹에서는 HTTP는 이미 사용중이었다. 기존 웹과 호환성을 유지하고 향상시킬수 있을까?
그리고 로이필딩은 논문을 썼다. 그렇게 REST가 탄생했다. - REST(2000)

 

분산 하이퍼미디어 시스템(예: 웹)을 위한 아키텍쳐 스타일

  • 나의 정의 : 웹(HTTP)에서 리소스를 접근, 전달하기 위한 아키텍쳐 스타일

REST API

  • Rest Api는 이런 아키텍쳐스타일을 따른는 제공되는 Api이다.

REST를 구성하는 스타일(가이드라인)

http만 잘따라도 client-server, stateless, cache,layered system을 잘따른다.

  • client-server : 클라이언트와 서버의 책임 구분, 클라이언트는 사용자 인증, 세션 같은부분을 담당하고 서버는 API 제공을 위한 비지니스 로직에 집중

  • stateless : 상태를 유지하지않음, 예를들어 유저의 세션정보같은거 유지 하지 않고, accssToken같은거를 이용한 상태유지

  • cache : http라는 웹표준을 사용했으므로 캐시가 가능

  • layered system : 서버를 다중 계층으로 구성 될수 있음, 비지니스 로직 서버와 앞단에 인증, 암호화 처리 , api gateway , proxy같은 레이어 가능

  • code-on-demand(optional) => Server에서 Code를 클라이언트로 보내서 실행할 수 있어야 한다.

  • uniform interface : 리소스에 대한 조작을 통일하고 한정된 인터페이스로 수행하는 아키텍쳐

    • identification of resources : resource가 uri로 식별한다.

    • manipulation of resources through representations : representations 전송을 통해서 resources를 조작해야한다.

      • representations이란 HTTP 메소드의 PUT, GET, DELTE 등을 말한다.

    • self-descriptive messages : 메시지 내용으로 온전히 해석이 가능해야한다

    • hypermedia as the engine of application state(HATEOAS) : 애플리케이션의 상태는 hyperlink를 이용해 전이되어한다

self-descriptive messages 

GET / HTTP/1.1
이 HTTP 요청 메시지는 뭔가 빠져있어서 self-descriptive하지 못하다.

GET / HTTP/1.1
Host : www.example.org
목적지를 추가하면 이제 self-descriptive 하다라고 말할 수 있다.

HTTP/1.1 200 OK

[ {"op" : "remove", "path" : "a/b/c/"} ]
self-descriptive하지 못하다. 어떻게 해석해야할지 모르기 때문이다.

HTTP/1.1 200 OK
Content-Type : application/json

[ {"op" : "remove", "path" : "a/b/c/"} ]
대괄호, 중괄호의 의미가 뭐인지 이해할 수 있기 때문에 파싱이가능해지고 문법을 해석할 수 있게 된다. 하지만 이것만으로는 부족한데 여기서 의미하는 "op"와 "path"의 의미를 모르기 때문이다.

HTTP/1.1 200 OK
Content-Type : application/json-patch+json

[ {"op" : "remove", "path" : "a/b/c/"} ]
json patch + json이라는 미디어 타입으로 정의되어 있는 메시지 이기 때문에 json patch라는 명세를 찾아가서 이것을 이해한다음에 메시지를 해석하면 올바르게 이 메시지의 의미를 해석할 수 있음
이 HTTP 요청 메시지는 뭔가 빠져있어서 self-descriptive하지 못하다

HATEOAS

잘지켜지지 않는다.

  (1) HTML은 HATEOAS를 만족한다. a 태그를 통해서 Hyperlink를 사용한 상태 전이가 가능하다.

  HTTP/1.1 200 OK

  Content-Type: text/html


  <html>

  <head></head>

  <body><a href="/test">test</a></body>

  <html>

	  
  (2) JSON은 HTTP의 Link header를 통해서 HATEOAS를 만족시킬 수 있다.

  HTTP/1.1 200 OK

  Content-Type: application/json

  Link: </article/1>; rel="previous",

  </article/3>; rel="next";


  {

  "title": "The second article",

  "contents": "blah blah.."

  }

 HATEOAS는 다음 그림과 같이 링크를 통해서 상태 전이가 되어야 한다는 것을 말한다.

 

왜 uniform interface를 해야 하는가?

독립적 진화
서버와 클라이언트가 각각 독립적으로 진화한다.
서버의 기능이 변경되어도 클라이언트를 업데이트할 필요가 없다.
REST를 만들게 된 계기 : "How do I imporve HTTP without breaking the Web"
REST API는 저 제약조건들을 다 지켜야 한다.

정리

REST API를 어떻게 설계하냐는 질문을 받은 기억있다.

설명을 잘못했지만 HTTP Method와 URI에 대해서만 답변을 했다. 다시 질문을 받았을때는 어떻게 대답을 할까?

REST의 기본 아키텍쳐 가이드에 대해서 설명하고, 설계시 중점을 두는 부분을 대답할것같다.

self-descriptive messages, HATEOAS는 실제로 지키기 위해서는 많이 노력이 필요하고, 실질적으로 서비스 구현에 이득이 없어 지키지 않는다고 답변할거 같다.

'개발' 카테고리의 다른 글

Redis 트랜잭션, Spring Data Redis  (0) 2020.03.31
Effective JAVA Exception처리  (0) 2020.03.30
Spring mvc NIO + webflux  (0) 2020.03.24
Mockito를 이용한 Unit테스트 Mocking  (0) 2020.03.22
Spring의 핵심 및 기술  (0) 2020.03.21
'개발' Related Articles more
Comments