REST API로 간단한 프로젝트를 만들어보고 있었는데 뭔가 만든다고는 하는데 막상 REST API가 뭔지 설명은 못하다가 좋은 영상을 보게 되었다.

 

 

REST API란 REST 아키텍쳐 스타일을 따르는 API로 REST는 서버와 클라이언트의 독립적인 진화를 위해 나오게 되었는데 REST를 구성하는 스타일은 다음과 같다.

 

1. client-server 구조

2. 무상태성(stateless)

3. cache

4. uniform interface

5. layered system

7. code-on-demand (Optional) - 서버에서 코드를 클라이언트로 보내서 실행할 수 있어야 한다. (Js)

 

대부분은 HTTP 특징을 잘 따르면 만족을 하는데 Uniform Interface는 처음 들어보는 용어인데 대부분 지키기가 어렵다고 한다.

 

Uniform Interface

 

1. identification of resources

2. manipulation of resources through representations

3. self-descriptive messages

4. hypermedia as ther engine of application state (HATEOAS)

 

 

1. identification of resources

리소스를 uri로 식별한다는 것으로 처음 Rest API를 공부할 때도 이 부분만 지키려고 했었다. (행위는 HTTP 메소드로 표현)

 

2. manipulation of resources through representations

representation이 조금 이해가 안 되어서 더 찾아보다가 좋은 글을 발견했다. (글을 쓰다 알았는데 위 영상에 나오시는 분이 이 글을 쓰신 분이였다..)

 

 

REST의 representation이란 무엇인가

사실 서버가 보내준 것은 리소스가 아니다. 다음과 같은 HTTP GET 요청을 서버에 보내서 GET Host: example.org Accept: text/plain, text/html; q=0.9 *; q=0.1 Accept-Language: en, ko; q=0.9, *; q=0.1 “hello”라는 메시지를 

blog.npcode.com

 

먼저 HTTP GET 메서드의 정의를 보면 Get 메서드가 타겟 리소스를 위해 현재 선택된 representation을 전송한다고 나와있다. 

The GET method requests transfer of a current selected representation
for the target resource.

 

이는 리소스를 표현하는 representation이 있고, replresentation이 하나 이상일 수 있으며 그 중 하나를 선택한다고 이해할 수 있다.

 

리소스는 HTTP 요청의 대상인데 회원에 대한 리소스를 요청을 했으면 아이디, 이름 등은 현재 회원이라는 리소스를 표현하는 데이터가 된다.

 

representation은 어떤 리소스의 특정 시점의 상태를 반영하고 있는 정보로 아이디가 바뀐다면 해당 리소스의 representation이 바뀌는 것이다.

 

김영한님 HTTP 강의에서 HTTP 표준 RFC7230 부분에도 나와있는데 Representation(표현)은 표현 메타데이터(헤더)와 표현 데이터(메시지 바디)로 구성이 되는데 표현 메타데이터는 표현 데이터를 해석할 수 있는 정보를 제공한다고 보면 된다. (Content-Type, Content_Lenght 등)

리소스에 대한 표현은 여러개가 될 수 있고 그 중 요청에 적합한 'a current selected representation' 을 선택해서 반환하는 것이다.

여기서 말하는 선택은 Request 요청 시 Accept 정보에 따라 서버에서 적절한 representation을 선택하는 것을 말하고 이를 협상(컨텐츠 네고시에이션)이라고 한다. (Accept-Language: ko 헤더를 추가하여 한국어 representation으로 응답을 받거나 Accept: text/html; charset=UTF-8을 추가하여 html로 응답을 받는 등 요청에 따라 응답이 달라진다.)

 

HTTP에서의 representation 개념은 REST에서 온 것인데 REST(Representational State Transfer)에서 State는 웹 애플리케이션의 상태를, Transfer은 상태의 전송을 의미한다.

브라우저가 보여주는 페이지가 바뀌는 것을 웹 애플리케이션의 상태가 변경되었다고 말하는데 표현(representation)을 통해 웹 애플리케이션의 상태(State)가 변경(Transfer)되는 것이다.  

 

이제 메시지 바디에 Representation을 담아서 리소스를 조작(생성, 변경, 삭제 등)한다는 것이 조금 이해가 되었다.

 

 

3. self-descriptive messages

self-descriptive message는 메세지가 스스로 설명 가능해야 한다는 것인데 json으로 응답을 하는 경우 Content-Type을 명시해주고 해당 json 값이 무엇을 의미하는지 json patch 명세를 확인해서 정의하는 등의 정보들을 제공해야한다.

 

 

4. hypermedia as ther engine of application state (HATEOAS)

HATEOAS는 애플리케이션의 상태가 하이퍼링크를 통해 전이가 되어야 한다는 것으로 HTML의 경우 단순하게 <a href=> 태그를 통해 그 다음 상태로 이동할 수 있고 json은 링크라는 것을 추가해서 다음 상태로 전이되도록 할 수 있다.

 

 

REST API는 대부분 Json으로 응답을 하기 때문에 HTML과 비교하면 self-descriptive, HATEOAS를 지키기가 어려운데 영상에 해결책이 나와있지만 확실히 HTML에 비해 까다로운 것 같다. 그래도 REST API가 무엇인지 이런 부분들을 좀 공부하니 내가 뭘 만드는지 조금 정리가 됐다.

 

간단하게 프로젝트에 스프링 HATEOAS를 추가해서 링크를 바디에 추가했는데 링크를 추가할 객체를 EntityModel.of()에 넣어주는데 new 생성자는 더 이상 사용 안하기 때문에 of()를 사용한다.

 

그리고 링크 빌더를 통해 readMemberList() 메서드의 url을 생성해주고 EntityModel에 담아서 보내면 되는데 사용자 리스트를 보여주는 메소드 링크를 연결하였다.

 

 

 

 

모든 개발자를 위한 HTTP 웹 기본 지식 - 인프런 | 강의

실무에 꼭 필요한 HTTP 핵심 기능과 올바른 HTTP API 설계 방법을 학습합니다., - 강의 소개 | 인프런...

www.inflearn.com

 

Spring Boot를 이용한 RESTful Web Services 개발 - 인프런 | 강의

이 강의는 Spring Boot를 이용해서 RESTful Web Services 애플리케이션을 개발하는 과정에 대해 학습하는 강의으로써, REST API 설계에 필요한 기본 지식에 대해 학습할 수 있습니다., - 강의 소개 | 인프런..

www.inflearn.com

 

RESTful API 설계 가이드

1. RESTful API 설계 가이드본 문서는 REST API를 좀 더 RESTful 하게 설계하도록 가이드할 목적으로 만들어졌다.따라서, 기본적인 REST API 개념 설명은 아래의 링크로 대신한다. REST API 제대로 알고 사용

sanghaklee.tistory.com

 

인터넷은 인터넷 프로토콜 TCP/IP를 기반으로 전 세계적으로 연결되어있는 컴퓨터 네트워트 통신망으로 흔히 웹이라고 부르는 월드 와이드 웹(www)을 포함해 동영상 스트리밍, 온라인 게임 등의 다양한 서비스를 지원한다.

 

월드 와이드 웹의 주요 기능은 URL을 통한 통일된 웹 자원의 위치 지정 방법, 웹의 자원에 접근하는 프로토콜(HTTP), HTML 언어로 문서들을 체계화하여 정보를 신속하게 교환할 수 있도록 데이터베이스를 구축하고 이를 전문 열람 소프트웨어로 열람하는 방식으로 탄생하였다.

 

인터넷 네트워크의 수 많은 노드를 거쳐서 데이터를 주고 받기 위해서 각각의 노드를 구분할 수 있는 IP 주소를 지정하고 패킷이라는 통신 단위로 데이터를 전송하는 인터넷 프로토콜(IP)이 등장했다. IP 패킷은 출발지 IP, 목적지 IP, 전송 데이터를 포함하는데 비연결성, 비신뢰성의  문제로 TCP 프로토콜이 나오게 된다. (IP 주소는 구분하기도 어렵고 변경 될 수 있기 때문에 DNS 방식을 통해 IP 주소를 특정 이름의 도메인 명으로 바꾸어 사용, google.com, naver.com)

 

웹 브라우저에서 SOCKET 라이브러리를 통해 HTTP 데이터를 전송하면 TCP 정보가 생성이 되고 이를 IP 패킷이 감싸게 된다. 

TCP3 way handshake라는 논리적인 가상 연결 방식과 PORT 정보와 전송 제어, 순서, 검증 정보 등으로 높은 신뢰성과 연결성을 가지는 프로토콜로 현재 대부분 TCP 프로토콜을 사용 (PORT : 같은 IP 내에서 프로세스를 구분하기 위한 번호, Http-80, Https-443)

 

URI인터넷에 있는 자원(식별할 수 있는 모든 것, Resource)을 나타내는 유일한 주소로 리소스의 위치를 지정하는 URL, 이름을 지정하는 URN 방식이 있는데 URN 방식은 실제 리소스를 찾기가 어려워서 거의 URL을 사용한다. (URI = URL)

URL은 프로토콜(https)과 호스트명(www.google.com), 포트 번호, 패스(/path) 경로, 쿼리 파라미터로 이루어져 있다.

 

 

[정리]

 

1. 웹 브라우저(애플리케이션 계층)에서 HTTP 메시지를 SOCKET 라이브러리를 통해 전송

2. 전송 계층은 HTTP 메시지에 TCP 헤더를 추가한 TCP 세그먼트를 생성해 인터넷 계층으로 전송

3. 인터넷 계층은 TCP 세그먼트에 IP 헤더를 추가한 IP 패킷을 생성하여 네트워크 계층으로 전송

4. 네트워크 계층은 TCP/IP 패킷을 이더넷 헤더를 추가해 이더넷 프레임을 생성하고 이를 전기 신호로 변환하여 인터넷으로 전송

5. 인터넷의 중간 노드(라우터)를 거쳐 목적지에 도착을 하면 네트워크 계층에서 이더넷 헤더의 MAC 주소를 읽어 자신의 데이터인지 확인

6. 이더넷 프레임에서 이더넷 헤더를 삭제한  IP 패킷을 인터넷 계층으로 전송

7. 인터넷 계층은 IP 헤더의 IP 주소를 확인하고 IP 헤더를 제거한 TCP 세그먼트를 전송 계층으로 전송

8. 전송 계층은 TCP 헤더를 검증하고 포트 번호를 확인하여 해당 포트의 애플리케이션에 HTTP 메시지를 전송

9. 애플리케이션 계층은 HTTP 헤더를 읽고 데이터를 처리

 

 

[참고] 인프런 김영한님 강의를 공부한 내용입니다.

[참고]https://better-together.tistory.com/93

+ Recent posts