Restful API

y0ung·2021년 1월 12일
0

JavaScript

목록 보기
10/20
post-thumbnail

REST

REST하다?

"웹에 존재하는 모든 자원(이미지, 동영상, DB자원)에 고유한 URI를 부여 해 활용" 하는 것으로, 자원을 정의 하고 자원에 대한 주소를 지정하는 방법론을 의미한다.

그래서 왜 REST가 이슈화 되었지?

큰 특징으로는 '애플리케이션 분리 및 통합', '다양한 클라이언트의 등장'이다.
애플리케이션의 복잡도가 증가하면서 애플리 케이션을 어떻게 분리하고 통합하느냐가 주요 이슈가 되었고, 이 에 자바 진영에서 과거 EJB(Enterprise Java Beans), SOA(Service Oriented Architecture)에 이어 최근에는 MSA(Micro Service Architecture)와 함께 RES가 떠오르고 있다. 그리고 모바일과 같은 다양한 클러이언트가 등장하면서, Backend하나로 다양한 Device를 대응하기 위해 REST의 필요성이 증대되었다.

REST란?

REST 구성

  • 자원(Resouce)-URI
  • 행위(Verb) - HTTP Method
  • 표현(Representations)

ex) 

/users GET
/users/{id} GET
/users PUT

REST의 특징

1. Uniform(유니폼 인터페이스)
HTTP 표준에만 따른다면, 안드로이드/IOS 플랫폼이든, 특정 언어나 기술에 종속되지 않고 모든 플랫폼에 사용이 가능하며, URI로 지정한 리소스에 대한 조작이 가능한 아키텍처 스타일을 의미한다.

2. Stateless(무상태성)
HTTP는 Stateless Protocol이므로, REST 역시 무상태성을 갖는다. 즉, HttpSession과 같은 컨텍스트 저장소에 상태정보를 따로 저장하고 관리하지 않고, API 서버는 들어오는 요청만을 단순 처리하면 된다. 세션과 같은 컨텍스트정보를 신경쓸 필요가 없어 구현이 단순해진다.

3. Cacheable (캐시가능)
HTTP기존의 웹 표준을 그대로 사용하므로, 웹에서 사용하는 기존의 인프라를 그대로 활용 가능하다. HTTP프로토콜 기반의 로드밸런서(mode_proxy)나, SSL은 물론이고 HTTP가 가진 가장 강력한 특징 중의 하나인 캐싱 기능을 적용할수 있다. 일반적인 서비스에서 조회 기능이 주로 사용됨을 감안하면, HTTP리소스들을 웹캐쉬 서버 등에 캐싱하는 것은 용량이나 성능 면에서 이점이 있다. 캐싱 구현은 HTTP프로토콜 표준에서 사용하는 Last-Modified태그나 E-Tag를 이용하면 가능하다.

캐시란?
웹 캐시는 자주 쓰이는 문서의 사본을 자동으로 보관하는 HTTP장치이다. 웹요청이 캐시에 도착했을 때, 태시된 로컬 사본이 존재한다면, 그 문서는 원 서버가 아니라 그 캐시로 부터 제공된다.

캐시의 이점은?

  • 불필요한 데이터 전송을 줄여서, 네트워크 요금으로 인한 비용을 줄여 준다.
  • 네트워크 병목을 줄여준다. 대역폭을 늘리지 않고도 페이지를 빨리 불어로 수 있게 된다.
  • 원 서버에 대한 요청을 줄여준다. 서버는 부하를 줄일 수 있으며 더 빨리 응답할 수 있게 된다.
  • 페이지를 먼 곳에서 불러올수록 시간이 많이 걸리는데, 캐시는 거리로 인한 지연을 줄여준다.

E-tag
: 메세지에 담겨있는 엔터티를 위한 엔터티 태그를 제공. 이를 활용하여 리소스를 식별할 수 있다.

Last-Modified
: 엔터티가 마지막으로 변경된 시각에 대한 정보를 제공(파일인 경우 파일 시스템이 제공해 준 최근 변경 시각, 동적으로 생성된 리소스라면 응답이 만들어진 시간)

4. Self-descriptiveness (자체 표현 구조)
동사(Method) + 명사(URI) 로 이루어져있어 어떤 메서드에 무슨 행위를 하는지 알 수 있으며, 메시지 포맷 역시 JSON을 이용해서 직관적으로 이해가 가능한 구조로, REST API 메시지만 보고도 이를 쉽게 이해할 수 있다.

5. Client - Server 구조
REST 서버는 API 제공, 클라이언트는 사용자 인증이나 컨텍스트(세션, 로그인 정보 등)을 직접 관리하는 구조로 각각의 역할이 확실히 구분되기 때문에 클라이언트와 서버에서 개발해야 할 내용이 명확해지고 서로간 의존성이 줄어들게 된다.

6. 계층형 구조
API 서버는 순수 비지니스 로직을 수행하고, 그 앞단에 사용자 인증, 암호화(ssl), 로드밸런싱 등을 하는 계층을 추가하여 구조상의 유연상을 둘 수 있다. 이는 간단하게는 HA Proxy나 Apache의 Reverse Proxy를 통해, 더 나아가서는 API gateway 등을 활용하여 Micro Service Architecture로도 구현이 가능하게 한다.

HTTP 응답코드 메소드

HTTP Request정보

  • GET /index.html HTTP/1.1
    : 요청 URL정보 (Mehotd /URI HTTP버젼)

  • user-agent: MSIE 6.0; Window NT 5.0
    : 사용자 웹 브라우져 종류

  • accept: test/html; */*
    : 요청 데이터 타입 (응답의 Content-type과 유사)

  • cookie:name=value
    : 쿠키(인증 정보)

  • refere: http://abc.com
    : 경유지 URL

  • host: www.abc.com
    : 요청 도메인

HTTP Response 정보

  • HTTP/1.1 200 OK
    : 프로토콜 버젼 및 응답코드

  • Server: Apache
    : 웹 서버 정보

  • Content-type: text/html
    : MIME 타입

  • Content-length : 1593
    : HTTP BODY 사이즈

  • <html><head>.....
    : HTTP BODY 컨텐츠

HTTP 메소드 정리

GET

요청 받은 URI의 정보를 검색하여 응답한다.

GET [request-uri]?query_string HTTP/1.1
Host:[Hostname] 혹은 [IP]

HEAD

GET방식과 동일하지만, 응답에 BODY가 없고 응답코드와 HEAD만 응답한다.
웹서버 정보확인, 헬스 체크, 버젼확인, 최종 수정일자 확인등의 용도로 사용된다.

HEAD [request-uri] HTTP/1.1
Host:[Hostname] 혹은 [IP]

POST

요청된 자원을 생성한다. 새로 작성된 리소스인 경우 HTTP헤더 항목 Location:URI주소를 포함하여 응답.

POST [request-uri] HTTP/1.1
Host:[Hostname] 혹은 [IP]
Content-Lenght:[Length in Bytes]
Content-Type:[Content Type]
[데이터]

PUT

요청된 자원을 수정한다. 내용 갱신을 위주로 Location: URI를 보내지 않아도 된다. 클라이언트 측은 요청된 URI를 그대로 사용하는 것으로 간주함.

PUT [request-uri] HTTP/1.1
Host:[Hostname] 혹은 [IP]
Content-Lenght:[Length in Bytes]
Content-Type:[Content Type]
[데이터]

PATCH

PUT과 유사하게 요청된 자원을 수정할 때 사용한다.
PUT의 경우 자원 전체를 갱신하지만, PATCH는 해당 자원의 일부를 교체 하는 의미로 사용

PATCH [request-uri] HTTP/1.1
Host:[Hostname] 혹은 [IP]
Content-Lenght:[Length in Bytes]
Content-Type:[Content Type]
[데이터]

DELETE

요청된 자원을 삭제 할 것을 요청함(안정성 문제로 대부분의 서버에서 비활성)

DELETE [request-uri] HTTP/1.1
Host:[Hostname] 혹은 [IP]

CONNECT

동적으로 터널 모드를 교환, 프락시 기능을 요청시 사용

CONNECT [request-uri] HTTP/1.1
Host:[Hostname] 혹은 [IP]

TRACE

원격시 서버에 루프백 메시지 호출하기 위해 테스트 용으로 사용

TRACE [request-uri] HTTP/ 1.1
Host: [Hostname] 혹은 [IP]

OPTIONS

웹서버에서 지원되는 메소드의 종류를 확인할 경우 사용.

OPTIONS [request-uri] HTTP/ 1.1
Host: [Hostname] 혹은 [IP]

HTTP POST와 PUT의 차이

POSTPUT
INSERT의개념UPDATE개념
멱등 X멱등 O
동일한 자원에 여러번 POST하면 서버자원에 변화가 생긴다.여러번 PUT하는 경우는 변화가 생기지 않는다.

예를 들어 POST의 경우 클라이언트가 리소스의 위치를 지정하지 않는 경우 사용된다.(/dogs)
따라서, 아래와 같은 요청이 여러번 수행되는 경우 매번 새로운 dog가 생성되어 dog/3, dog/4등 매번 새로운 자원이 생성된다. 멱등하지 않다는 말

POST /dogs HTTP/1.1
{"name":"blue", "age":5 }
HTTP/1.1 201 Created

반면 PUT의 경우는 클라이언트가 명확하게 리소스의 위치를 지정한다.(/dogs/3)
따라서, 아무리 많이 수행되더라도 리소스의 위치가 지정 되어 새로운 자원이 생성되지 않으며 동일한 리소스(/dogs/3)를 수정하기 때문에 여러번 요청하더라도 멱등하다.

PUT /dogs/3 HTTP/1.1
{"name":"blue", "age":5 }

HTTP PUT과 PATCH의 차이

PUT이 해당 자원의 전체를 교체하는 의미를 지니는 대신, PATCH는 일부를 변경한다는 의미를 지니기 때문에 최근 update 이벤트에서 PUT보다 더 의미적으로 적합하다고 평가받고 있다. 또한 PUT의 경우는 멱등하지만, PATCH의 경우는 멱등하지 않다. PUT은 전체 자원을 업데이트 하기 때문에 동일 자원에 대해서 동일하게 PUT을 처리하는 경우 멱등하게 처리된다. 반면 PATCH로 처리되는 경우 자원의 일부가 변경되기 때문에 멱등성을 보장할 수 없다.

HTTP멱등성

멱등(idempotent)의 의미는 같은 작업을 계속 반복해도 같은 결과가 나오는 경우를 의미한다. 동일한 자원에 대한 GET요청이라면 클라이언트에 반환되는 모든 응답은 동일해야 한다. 특정 자원에 대한 DELETE의 경우도 자원은 더이상 이용할수 없어야 하며, DELETE요청을 다시 호출한 경우도 자원은 여전히 사용할 수 없는 상태여야 한다.

출처

https://brainbackdoor.tistory.com/53
https://javaplant.tistory.com/18

profile
y0ung
어제보다는 오늘 더 나은
이전 포스트

브라우저 저장소

다음 포스트

Web Worker(multi thread)

0개의 댓글