web, api, rest

2021. 12. 7. 08:52

웹(Web)의 개념

월드 와이드 웹(World Wide Web)이란 인터넷에 연결된 사용자 들이 서로의 정보를 공유할 수 있는 공간을 의미합니다.

간단히 줄여서 WWW나 W3라고도 부르며, 간단히 웹(Web)라고 가장 많이 불려집니다.

인터넷과 같은 의미로 많이 사용되고 있지만, 정확히 말해 웹은 인터넷 상의 인기 있는 하나의 서비스일 뿐입니다.
하지만 현재에는 인터넷과 웹이라는 단어가 서로 혼용되어 사용될 만큼 인터넷의 가장 큰 부분을 차지하고 있습니다.

웹(Web)의 특징

웹은 인터넷 상에서 텍스트나 그림, 소리, 영상 등과 같은 멀티미디어 정보를 하이퍼텍스트 방식을 연결하여 제공합니다.
하이퍼텍스트(hypertext)란 문서 내부에 또 다른 문서로 연결되는 참조를 집어 넣음으로서 웹 상에 존재하는 여러 문서끼리 서로 참조할 수 있는 기술을 의미합니다.
이 때 문서 내부에서 또 다른 문서로 연결되는 참조를 하이퍼링크(hyperlink)라고 부릅니다.

웹에서는 HTML이라는 언어를 사용하여 누구나 자신만의 문서를 작성할 수 있습니다.
또한, 이렇게 작성된 웹상의 문서에는 Http라는 프로토콜을 사용하면 누구나 검색하고 접근할 수 있습니다.

웹(Web)의 구성

웹에서는 HTML언어를 사용하여 작성된 하이퍼텍스트 문서를 웹 페이지(web page)라고 부릅니다.
이러한 웹 페이지들 중에서 서로 관련된 내용으로 작성된 웹 페이지들의 집합을 웹 사이트(web site)라고 합니다.

웹은 이렇게 작성된 수많은 웹 페이지들이 하이퍼링크를 통해 서로 연결되어 구성됩니다.

사용자가 웹페이지에 포함된 하이퍼링크를 따라 다른 웹 페이지들로 계속하여 이동하는 것을 웹 서핑(web surfing)이라고 부르며, 이 때 사용자가 웹 페이지를 검색하기 위해 사용하는 프로그램을 웹 브라우저(web browser)라고 합니다.

흔히 웹 사이트(web site)와 홈페이지(home page)라는 용어를 같은 의미로 사용하는 경우가 많습니다.
사실 홈페이지(homepage)의 정확한 의미는 익스플로러나 크롬과 같은 웹 브라우저가 시작될 때 맨 처음 자동으로 표시되는 웹 페이지나 웹 브라우저의 홈 버튼을 누를 때 이동되는 웹 페이지를 지칭합니다.

하지만 웹 사이트와 홈페이지를 같은 의미로 사용해도 큰 문제는 없습니다.

정리

web이란 인터넷에 연결된 사용자들이 서로의 정보를 공유할 수 있는 공간을 의미합니다.

인터넷상의 인기 있는 하나의 서비스입니다.

멀티미디어 정보(텍스트, 그림, 소리, 영상 등고 ㅏ같은 멀티미디어 정보를 하이퍼텍스트 방식으로 연결하여 제공합니다.)

하이퍼 텍스트란?
문서 내부에 또 다른 문서로 연결되는 참조를 넣음으로써 웹 상에 존재하는 여러 문서끼리 서로 참조할 수 있는 기술

Web Api란?

HTTP 프로토콜을 사용하여 액세스 할 수있는 웹을 통한 API → 기술이 아니라 개념입니다.

REST Api란?

rest라는 것은 웹 서비스에서 많이 사용되는데 application사이에 결합도를 낮추게끔 설계하는 아키텍처 스타일

다양한 클라이언트들에게 정보를 제공하는 방법을 하나로 정하기 위해 web api + 여러가지 제약조건(rest 아키텍쳐를 따르는)이 추가된 API입니다.

탄생 배경

"웹을 망가뜨리지 않고 어떻게 http 기능을 증가시킬 수 있을까?"라는 고민에서 시작됨 - 로이 필딩

REST를 구성하는 스타일 6가지

Client - Server(클라이언트와 서버의 구조)
REST 서버는 API를 제공합니다.
하나의 REST API를 여러 클라이언트에서 이용할 수 있습니다.
서버(Rest Server)에서는 비즈니스 로직 처리 및 Data 저장을 책임집니다.
클라이언트의 경우 사용자 인증이나 컨텍스트(세션, 로그인 정보
) 등을 직접 관리하고 책임지는 구조로 서버와 클라이언트의 역할이 나뉘어 지고 잇습니다.
Stateless(무상태성)
REST는 상태 정보를 따로 저장, 관리하지 않습니다.
세션이나 쿠키 정보를 별도로 저장, 관리하지 않으므로 api서버는 들어오는 request만 단순 처리하면 됩니다.
이는 곧 서비스의 자유도가 높아지고 서버에 불필요한 정보를 관리하지 않으므로 구현이 간결해집니다.
ex) 로그인 - 서버에서 클라이언트의 상태를 저장, 관리하지 않는다.(jwt와 같은 기술을 사용하여 관리)
Cache (캐시 가능)
REST의 가장 큰 특징은 HTTP라는 기존의 웹 표준을 그대로 따른다는 것입니다.
이 말은 곧, 기존의 웹 자원들을 그대로 활용할 수 있다는 점입니다.
따라서 HTTP가 가진 캐싱(임시 저장) 기능이 적용가능합니다.

Uniform (유니폼 인터페이스)
rest는 HTTP표준에만 따른다면, 안드로이드/IOS 플랫폼이든, 특정 언어나 기술에 종속되지 않고 모든 플랫폼에 사용할 수 있으며, URI로 지정한 리소스에 대한 조작이 가능한 아키텍처 스타일을 의미한다.
layered system(계층형 구조)
rest 서버는 다중 계층으로 구성될 수 있으며 보안, 로드 밸런싱, 암호화 계층을 추가해 구조상의 유연성을 둘 수 있고 PROXY, 게이트웨이 같은 네트워크 기반의 중간매체를 사용할 수 있게 한다.
-> RESTful한 서버는 보안, 로드밸런싱, 인증 등의 여러 계층으로 구성될 수 있다.(모듈화된 프로그램을 만들 듯이 각 계층을 분리시켜서 좀 더 오류를 찾기 쉽고, 관리 하기 쉽도록 하기 위해서라고 이해했습니다.)
클라이언트는 server의 정해진 url에 요청을 보내기만 하면 되고, 서버는 다양한 layer를 이용해 작업할 수 있다.
Code-On-Demand (선택적 제약 조건)
서버로 부터 스크립트를 받아서 Client에서 실행하는 것입니다.반드시 충족할 필요는 없습니다.

uniform interface를 만족시키는 4가지 조건

1) identification of resources

Resource가 URI로 식별되야한다.

2) manipulation of resources through representations

representations 전송을 통해서 resources를 조작해야한다.

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

대상 정보의 자원
- GET /members: members의 모든 정보가 대상
- DELETE /members/1: members 중 1이 대상
자원에 대한 행위
- 올바른 표현: GET /members/1, POST /members, PUT /members/1, DELETE /members/1
- 틀린 표현: GET /members/get/1, GET /members/add, GET /members/update/1, GET /members/del/1
  - 조회, 입력, 수정, 삭제(get, post, put, delete)와 관련된 명령이 중간에 동사로 중첩되어 표현되면 안 됨(http 메소드를 동사로 사용하기 때문)
  - 어떤 행위를 해야 하는지가 HTTP 메서드로 명확히 전달되어야 함

3) Self-descriptive messages

메시지는 스스로를 설명해야한다.

예시를 봅시다!!

GET / HTTP/1.1

위의 메시지는 단순히 root를 가져오는 GET요청입니다.
이 HTTP 요청 메시지는 무언가가 빠져있어 Self-descriptive하지 못합니다.

http 버젼과 메소드는 명시되어 있지만 목적지가 빠져있다.
이 요청이 어느 도메인 or ip주소를 가진 Host로 간다라는 목적지가 빠져있기 때문에 이런 경우는 Self-descriptive하지 않다고 합니다!

GET / HTTP/1.1
Host: www.example.org

추가적으로 이런 경우도 생각할수 있습니다.
아래는 상태코드 200의 response 메시지이며, JSON 본문이 있습니다.

HTTP/1.1 200 OK

[ { "op": "remove", "path": "/a/b/c" } ]

이렇게 되면 당연히 Self-descriptive하지 않는데
클라이언트 입장에서 이 response를 해석할 때 어떤 문법으로 작성된 것인지 모르기 때문에 해석을 할 수 없기 때문이다.
그렇기 때문에 Content-Type 헤더가 반드시 들어가야한다.

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

[ { "op": "remove", "path": "/a/b/c" } ]

이렇게 까지 작성 됬다면 대괄호, 중괄호, 큰따옴표가 뭘 의미하는지 알게 되어, 파싱이 가능하여 문법을 해석할 수 있게 된다.
그럼 이제 Self-descriptive하다고 할 수 있을까? NO!!! (여기까지가 대부분의 restful api가 지키는 수준)

만약 json data를 파싱했다고 하더라도, op key는 무슨 뜻이고, path의 값은 어떤걸 의미하는 건지 알 수 없다.(안 적혀 있으니까)

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

[ { "op": "remove", "path": "/a/b/c" } ]

이런 식으로 patch+json와 같은 미디어 타입까지 정의된 메시지라면 json_patch라는 명세를 찾아보고 이해한 다음, 명세에 따라 이 메시지를 해석하고 그제서야 올바르게 메시지의 의미를 이해할 수 있게 됩니다.
하지만 오늘날의 REST API는 상당히 이를 만족하지 못하고 있다. 대부분 미디어 타입에는 그냥 json이라고만 되어있고 이를 어떻게 해석해야되는지는 명시가 되어있지 않다.

http://jsonpatch.com/ - 이런 식으로 공식 문서에 명시되어 있는 명세들
IANA 에서 미디어타입 등록도 가능합니다. - 사용하는 인원이 소수이고 모두 숙지, 이해하고있다면 등록 필요 X

4) HATEOAS

애플리케이션의 상태는 Hyperlink를 이용해 전이되어야 한다.

예를 들어 아래와 같은 사이트가 있다고 해보자

루트 홈페이지 → 글 목록 보기 GET → 글 쓰기 GET → 글 저장 POST → 생성된 글 보기 GET → 목록 보기 GET → ...

이렇게 상태를 전이하는 것을 애플리케이션 상태 전이라고 하고, 이 상태 전이마다 항상 해당 페이지에 있던 링크를 따라가면서 전이했기 때문에 HATEOAS라고 할 수 있다. 말 그대로, 하이퍼 링크를 통한 전이가 되는 것이다.

그래서 html 같은 경우를 보면 HATEOAS를 만족하게 되는데,

HTTP/1.1 200 OK
Content-Type: text/html

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

a 태그를 통해서 하이퍼링크가 나와 있고, 이 하이퍼 링크를 통해서 그 다음 상태로 전이가 가능하기 때문에 만족한다고 볼 수 있다.

Json으로 작성한다면?

HTTP/1.1 200 OK
Content-Type: application/json
Link: </articles/1>; rel="previous",
            </articles/3>; rel="next";

{
    "title": "The second article",
    "contents": "blah blah..."
}

위와 같이 Link 헤더를 활용하여 작성할 수 있습니다!

정리

오늘날 대부분 "REST API"는 사실 REST를 따르고 있지 않다.
REST의 제약 조건 중 특히 self-descriptive와 HATEOAS를 잘 만족하지 못한다.
REST를 따를 것인지는 API 설계하는 이들이 스스로 판단하여 결정
REST를 따르겠다면 Self-decriptive와 HATEOAS를 만족시켜야한다. → 가장 많이 안지켜지는 두 가지입니다!!
- Self-decriptiv는 custom media type, profile link relation으로 만족 가능
- HATEOAS는 HTTP 헤더나 본문에 링크를 담아 만족 가능
REST를 따르지 않겠다면, "REST를 만족하지 않는 REST API"를 뭐라고 부를지 결정해야할 것이다.
- HTTP API라고 부를 수도 있고
- 그냥 이대로 REST API라고 부를 수도 → 로이 필딩이 싫어합니다!