기술 면접 준비 - HTTP 기본 (2)

HTTP란?

텍스트 기반 통신 규약으로 인터넷에서 데이터를 주고받을 수 있는 프로토콜이다.

• 비연결지양(Connectionless) - 요청과 응답을 한 번씩 주고받으면 연결을 끊음
• 상태없음(Stateless)

웹 문서간 링크를 통해 연결할 수 있는 프로토콜이며, 문서 뿐만 아니라 html, text, 이미지, 음성, 영상, 파일, json, xml, 등 다양한 종류의 데이터를 폭 넓게 전송할 수 있다.

Stateless한 HTTP

Stateless

아케텍쳐 스타일 제약 조건 중 하나로 서버에서 상태를 관리하지 않는 것을 뜻한다. 서버에 상태를 저장하지 않기 때문에 세션관리를 위해서는 서버가 세션 상태를 알게 하기 위한 다른 방법이 필요하다.

→ 클라이언트가 세션 상태를 매번 전달해주는 방식을 취할 수 있는데, 이때 상태를 포함하고 있는 메세지를 자기 기술적 메세지라고 부른다.

 

장점 - 확장성 높음

단점- 퍼포먼스

 

자기 기술적 메세지를 사용하기 때문에 메세지의 데이터가 커지고 네트워크 대역폭을 많이 사용하게 된다. → 퍼포먼스 저하

스테이트리스는 로그인이 필요한 서비스 구현이 어렵다. 때문에 브라우저 쿠키와 세션을 활용하여 상태를 유지한다. (상태 유지는 최소화 해야 한다)

상태 : 사용자가 로그인할때부터 로그아웃할 때 까지 행하는 일련의 조작을 저장하는 세션 상태를 의미

http는 각 요청이 독립적으로 실행되고, 이전에 실행된 요청에 대한 정보를 알지 못하기 때문에 stateless라고 한다.

URL URI URN

URL은 일종의 URI이다.

URL(Uniform Resource Locator)

• 자원의 정확한 위치 정보(파일의 위치)를 나타냄
• URL을 통해 Resource가 어디에 있는지, 어떻게 접근할 수 있는지 알 수 있음

<https://hstory0208.tistory:3000/category?category=network&page=5#url차이>

scheme host(domain) :port /path ?query #fragment

http://

hstory0208.tistory

3000

category

category=network&page=5

#url차이

• scheme : 통신 프로토콜 결정
• host: 웹페이지, 이미지, 동영상 등의 파일이 위치한 웹 서버, 도메인 또는 IP
• :port :웹서버에 접속하기 위한 통로
• /path : 웹서버의 루트 디렉토리로부터 웹페이지, 이미지, 동영상 등 파일 위치까지의 경로
• ?query : 리소스의 형식 범위를 좁히기 위한 추가 질문
• #fragment : URL이 지정하는 자원의 세부 부분을 지정할 때

category까지 URL, 이후부터는 식별자가 붙었기 때문에 URI(URL을 포함한 URI)

 

URN(Uniform resource Name)

• Resource의 위치와 상관없이 식별 가능한 고유한 이름 역할을 한다.
• 이름이 변하지 않는 한 리소스 위치가 변경되더라도 문제없이 동작

URI(Uniform Resource Identifier)

• 가장 큰 개념
• 자원의 위치 뿐만 아니라 자원에 대한 고유 식별자로서 URL을 포함
• 하위 개념으로 URL과 URI가 있다.

HTTP method

주요 메소드는 다음과 같이 5가지가 있다. (그 이상도 존재)

• GET
• POST
• PUT
• PATCH
• DELETE

GET

리소스 조회 메서드(Read)

전달을 희망하는 데이터는 쿼리스트링 을 통해 전달

GET /member/100?username=lisa

쿼리스트링 외에 메세지 바디를 사용하여 데이터를 전달 가능하지만 서버에서 따로 구성해야 하기 때문에 권장하지 않음

POST또한 조회가 가능하지만 GET 메서드는 캐싱이 가능하기 때문에 GET을 쓰는 것이 유리

• 정적 데이터 조회 : 쿼리 파라미터 없이 리소스 경로로 단순하게 조회 가능(이미지, 정적 텍스트 문서)
• 동적 데이터 조회 : 검색, 게시판 목록에서 검색어로 이용. 쿼리 파라미터를 통해 데이터를 전달.

form 데이터를 통해 GET으로 데이터 전송 가능하지만 form은 get, post만 가능

 

POST

전달한 데이터 처리/생성 요청 메서드(Create)

메시지 바디를 통해 서버로 요청 데이터를 전달하면 요청 데이터를 처리하여 업데이트

신규 리소스 등록, 프로세스 처리에 사용

데이터를 GET 하는데 있어서 JSON으로 조회 데이터를 넘겨야 하는 애매한 경우 POST를 사용

POST /members
Content-Type: application/json

{
	"username":"young",
	"age":20
}

• 신규 자원 생성은 201이나 200으로 응답을 보낸다.
• Location은 자원이 신규로 생성된 URI 경로를 의미한다.

form 데이터 전송

• 회원가입, 상품주문, 데이터 변경에 이용
• GET, POST 만 지원
• input 태그안에 들어간 값들이 쿼리스트링으로 서버에 전송됨
• Content-Type : application/x-www-form-urlencoded

PUT

리소스를 대체(수정)하는 메서드(Update)

요청 메세지에 리소스가 있으면 덮어쓰고, 없으면 새로 생성한다.

데이터를 대체해야 하기 때문에 클라이언트가 리소스의 구체적인 전체 경로를 지정하여 보내야 한다.

PUT /members/100

• 일부 데이터만 보낼 경우, 기존 데이터가 삭제되고 일부 데이터로 대체된다.

DELETE

리소스를 제거하는 메소드

상태코드는 기본적으로 200을 사용하고 상황에 따라 204를 사용한다.

 

PATCH

일부 리소스만 변경하는 메서드(Update)

patch를 지원하지 않는 서버일 경우, 대신 POST를 사용할 수 있다.

HTTP header

크게 네가지가 있다.

• General Header(공통 헤더)
• Request Header(요청 헤더)
• Response Header(응답 헤더)
• Entity Header(엔티티 헤더)

공통 헤더

요청 및 응답의 메세지 모두에서 사용되지만 컨텐츠에는 적용되지 않는 헤더

• Date
• Connection
• Cache-Control
• pragma
• Trailer

Request Header

요청 헤더는 HTTP 요청에서 사용되지만 메시지의 컨텐츠와 관련 없는 HTTP 헤더

fetch될 리소스나 클라이언트 자체에 대한 정보를 포함하여 서버로 보내진다.

서버로 요청할 데이터의 정보가 담겨있는 헤더

• Host
• User-Agent
• Accept
• Authorization
• Origin
• Referer

Response Header

위치 또는 서버 자체에 대한 정보와 같이 응답에 대한 부가적인 정보를 갖는 헤더이다.

• Access-Control-Allow-Origin →CORS 허용 세팅
• Allow
• Content-Disposition
• Location
• Content-Security-Policy

Http 엔티티 관련 헤더

컨텐츠 길이나 MIME 타입과 같이 Entity Body에 대한 자세한 정보를 담은 헤더

• content-type
  • 해당 개체에 포함되는 미디어 타입 정보
  • Content-Type:text/html; charset-latin-1 - 해당 개체가 html 문서이고 iso-latin-1 문자 인코딩 방식으로 표현
  • 공통헤더
• Content-Language
  • 해당 개체와 어울리는 사용자 언어(자연언어)
• Content-Encoding
  • 데이터 압축 방식
  • Content-Encoding:gzip, deflate
  • 위의 두개 항목을 기반으로 합축 해제 가능

Content-Type 종류

• application/x-www-form-urlencoded :
  • Form 내용을 hTTP 메세지 바디를 통해 전송(쿼리 파라미터),
  • 전송 데이터 url encoding 처리
• multipart/form-data
  • 파일 업로드 같은 바이너리 데이터 전송시 사용
  • 다른 종류의 여러 파일과 FORM의 내용 함께 전송 가능
• application/json
  • TEXT, XML, JSON 데이터 전송시 사용

타입을 넣는 필드 이름은 무엇인가? - HTTP 헤더의 Content-Type에 어떤 타입의 데이터를 전송할지 작성할 수 있다.

CORS

CORS란 무엇인가?

Cross origin resource sharing으로 출처가 다른 자원들을 공유한다는 뜻이다.

추가 HTTP 헤더를 사용하여 한 출처에서 실행 중인 웹 어플리케이션이 다른 출처의 선택한 자원에 접근할 수 있도록 권한을 부여하고 브라우저에 알려주는 체제다.

 

출처

protocol+host+port 3가지가 같으면 동일한 출처라고 한다.

CORS 정책이 없다면 누군가에 의해 검증되지 않는 출처로 접근되어 중요 개인 정보가 유출되어버리는 문제가 발생할 수도 있다. → 다른 출처의 공격을 사전에 예방하고 다른 출처 리소스에 접근성을 높이기 위해 CORS 정책이 존재한다.

1. 단순 요청 - GET, HEAD, POST 만 가능
2. preFlight Request - 테스트로 요청을 한 번 보내 안전한지 확인 후 본래 요청을 보냄
3. 신용 요청 - 쿠키, 인증 헤더, TLS 클라이언트 인증서 등의 신용정보와 함꼐 요청

프리플라이트 사용 추천

크라이언트 사이드 CORS 우회 → 개발할 때 사용되는 방법

1. 원활한 개발 환경을 구축하기 위해 webpack dev server에서 제공하는 proxy 기능을 사용하여 간단하게 CORS를 우회할 수 있다. webpack dev server의 프록시를 이용하면 백엔드 서버에 직접 API를 요청하지 않고 현재 개발 서버의 주소로 우회 요청을 하게 된다. → 전역적 설정
2. http-proxy-middleware 라이브러리 사용 - setupProxy.js에서 설정

SSL

HTTP와 HTTPS

http는 TCP와 직접 통신하지만 HTTPS에서는 SSL과 통신하고 SSL이 TCP와 통신한다는 차이점이 있다.

이를 통해 SSL을 사용한 HTTPS는 암호화와 증명성, 안전성 보호를 이용할 수 있게 되었다.

HTTP HTTPS

의미	Hypertext Transfer Protocol	Hypertext Transfer Protocol Secure
용도	이전 텍스트 기반 웹사이트	모든 최신 웹사이트
보안	추가 보안 기능 없음	퍼블릭 키 암호화에 SSL 인증서 사용
이점	인터넷을 통한 통신 지원	웹사이트에 대한 권위, 신뢰성 및 검색 엔진 순위 개선

HTTPS는 HTTP보다 리소스를 많이 잡아먹는다.

 

TCP/IP

패킷 - 데이터를 패킷이라고하는 작은 단위로 나누어 전송하는 방식을 의미.

IP- 인터넷 프로토콜

• IP는, 패킷 데이터들을 최대한 빨리 특정 목적지 주소로 보내는 프로토콜.
  • 빨리 보내는게 목적이기 때문에,
  • 패킷 전달 여부를 보증하지 않으며, 패킷을 보낸 순서와 받는 순서가 다를 수 있다.

TCP - 전송 조절 프로토콜

• 패킷 통신은, 데이터를 작은 단위로 나누어 전송하기 때문에, 순서가 뒤섞이거나 내용이 유실될 수 있다는 단점이 있습니다.
• 따라서, 이러한 문제를 해결하기 위해 TCP 라는 프로토콜이 존재합니다.
• TCP는, 패킷을 정상적으로 받을 수 있도록 하는 프로토콜입니다.
  • 꼼꼼하게 보내는게 목적이기 때문에, IP 보다 패킷 전송 속도는 느리지만,
  • 패킷 전달 여부를 보증하고, 패킷을 송신 순서대로 받게 해줍니다.
  • 즉, 목적지에 도착한 패킷들을 순서대로 정렬하고, 손상되거나 손실된 패킷이 있다면, 출발지에 재요청하는 방식으로 진행됩니다.

SSL

• 암호화 기반 인터넷 보안 프로토콜이다.
• 전달되는 모든 데이터를 암호화하고 특정한 유형의 사이버 공격도 차단할 수 있다.
• SSL은 TLS 암호화의 전신이기도 하다.

TLS

SSL의 업데이트 버전으로 기존의 SSL에 대한 소유권 변경을 위해 이름이 바뀐 것이다.(명칭만 다르다)

SSL 3.0과 TLS 최초 버전은 거의 유사하다.

• 암호화:제 3자로부터 전송되는 데이터를 숨긴다.
• 인증 : 정보를 교환하는 당사자가 요청된 당사자임을 보장
• 무결성: 데이터가 위조되거나 변조되지 않았는지 확인

SSL/TLS는 웹에서 전송되는 데이터를 암호화하고, 복호화가 거의 불가능하며, 클라이언트와 서버산의 헨드세이크를 통해 인증이 이뤄진다. 또 데이터 무결성을 위해 디지털 서명을 하여 조작 여부를 확인한다.

ssl/tls 차이 → ssl 3.0에 대하여 설명하기

둘다 안전한 연결을 제공한다는 특징이 있다.

그림으로 쉽게 보는 HTTPS, SSL, TLS

1. 핸드셰이크 프로세스: SSL 핸드셰이크는 명시적 연결이며, TLS 핸드셰이크는 암시적 연결입니다. SSL 핸드셰이크 프로세스는 TLS 프로세스보다 단계가 더 많다. TLS는 추가 단계를 제거하고 총 암호 그룹 수를 줄여서 프로세스 속도를 높였다.
2. 알림 메시지: SSL에는 경고와 치명적이라는 두 가지 알림 메시지 유형만 있다. TLS에는 닫기 알림이라는 추가 알림 메시지 유형이 있습니다. 또한 TLS 알림은 추가 보안을 위해 암호화된다
3. 메시지 인증: SSL과 TLS 모두 메시지의 진본성과 무결성을 확인하기 위한 암호화 기술인 메시지 인증 코드 (MAC)를 사용한다. SSL 프로토콜은 MAC 생성에 MD5 알고리즘 (현재는 구식)을 사용한다. TLS는 더 복잡한 암호화와 보안에 해시 기반 메시지 인증 코드 (HMAC)를 사용한다
4. 암호 그룹: 암호 그룹은 브라우저와 서버 간의 정보를 암호화하기 위한 키를 생성하는 알고리즘 모음입니다. 보안 문제로 인해 TLS의 여러 알고리즘이 SSL에서 업그레이드 되었다
5. 인증서: 현재 모든 SSL 인증서가 더 이상 사용되지 않습니다. TLS 인증서가 업계 표준입니다. 그러나 업계에서는 TLS 인증서를 지칭하는 데 SSL 이라는 용어를 계속 사용한다

간단히 말해, SSL은 더 이상 사용되지 않으며, TLS는 현재 모든 사람이 사용하는 암호화 표준으로 구식 SSL 프로토콜을 대체하는 새로운 용어이다. 기술적으로 TLS가 더 정확하지만 SSL이 널리 사용된다.

공개키 암호화, 대칭키 암호화

HTTPS와 SSL인증서 & 대칭키, 공개키(비대칭키)

키란 암호화를 진행할 때 사용되는 비밀번호화 같은 역할을 한다.

 

대칭키

• 암호화에 사용되는 키와 복호화에 사용되는 키가 동일한 암호화 기법이다.
• 암호화 할 때 A키를 사용하였다면, 복호화 할 때도 A를 사용한다.

→ 암호화와 복호화를 위한 키의 공유가 어렵다. 대칭키가 유출되면 누구나 복호화를 할 수 있기 때문에 암호가 무용지물이 된다. 이러한 단점을 보완한 암호화 방식이 공개키 방식

 

공개키

두 개의 키를 갖는다. A키를 이용해 암호화를 하면, B키로 복호화를 할 수 있다. B 키로 암호화를 하면 A키로 복호화를 할 수 있다. → 쌍을 이루는 키를 통해서 복호화가 가능하다.

이러한 방식을 통해 두 개의 키 중 하나를 개인키로 하고 나머지 하나를 공개키로 지정하여 대중에 공개한다.

• 보안 향상
• 암호화된 정보의 출처 검증 가능 → CA(클라이언트가 접속한 서버가 의도한 서버가 맞는지 보장해주는 역할을 함)

공개키 방식은 컴퓨팅 파워를 많이 사용하여 성능적 문제가 발생할 수 있다.

Cache

캐싱

한번 가져온 데이터를 가까운 곳에 저장해두고 다음번에 저장해둔 것을 사용하는 일종의 성능 향상 기법

• private Cache : 브라우저 캐시 - 사용자가 HTTP 요청을 통해 다운로드한 문서를 웹 브라우저에서 모두 저장하고 있다가 앞으로가기 혹은 뒤로가기를 할 때, 페이지 소스 보기를 할 때 등 재활용된다.
• Shared Cache : Proxy Cache - 기업 로컬 네트워크 인프라 일부로 구축해둔 웹 프록시를 통해 이러한 역할 담당 가능. 최초의 HTTP 요청 —> 공유 캐시 → 서버 → HTTP 응답 이후 두 번째 동일한 요청이 공유캐시에 전달될 때 서버에 해당 요청을 보내지 않고 저장된 HTTP 응답을 클라이언트에게 반환한다.

Proxy cache

Proxy

클라이언트와 서버 사이에 대리로 통신을 수행하는 것. → 그중 중계 기능을 하는 서버를 프록시 서버라고 한다.

프록시 캐시는 공유 캐시의 일종이고, 클라이언트가 요청을 할 때 서버 사이에 프록시 캐시 서버가 있다면 여기서 데이터를 가져올 수 있고, 많은 사람들이 찾은 자료일수록 캐시에 이미 등록되어 있으면 빠른 속도로 데이터를 가지고 올 수 있다.

Cache Control이란?

HTTP 헤더에서 캐시 매커니즘을 제어할 디렉티브(특정 기능이나 동작을 가진 코드)를 정의하는데 사용 위해 사용되는 헤더다.

• max-age=<seconds> : 리소스의 최대 유효시간을 지정
• public : 응답이 어떤 캐시에 의해서든 캐싱된다는 것을 나타냅
• private : 응답이 단일 사용자를 위한 것이며 공유 캐시에 의해 저장되지 않아야 한다는 것을 나타냄

**캐시 무효화 디렉티브(**캐시를 무효화 하는 방법은 무엇이 있을까?)

• no-cache: 유효 기간이 남아있어도 캐시 저장소를 초회하지 않고 서버에서 검증을 받도록 강제(항상 원 서버에 검증하고 사용)
• no-store : 캐시는 클라이언트 요청 혹은 서버 응답에 관한 어떤것도 저장해서는 안됨
• must-revaildate:캐시 만료 이후 최초 조회 시 검증이 필요.(유효기간 동안은 사용 가능)

이때 no-caahe는 네트워크 단절이나 접근 불가일 경우 오류가 아닌 200OK를 응답으로 보내며, must-revaildate는 504 게이트웨이 타임아웃을 내뱉는다.

 

이외

• CDN,
• Reverse Proxy Cache
• Load Balancer

웹사이트 성능 향상, 서버 부하 줄임, 사용자 경험 개선에 도움이 된다.

ETag

HTTP에서 ETag(Entity Tag)의 의미와 사용법

ETag는 웹 서버와 클라이언트 간의 통신에서 사용되는 캐싱 매커니즘이다. 리소스의 변경 여부를 빠르게 확인할 수 있다.

HTTP/1.1 200 OK
Content-Type: text/html
ETag: "d41d8cd98f00b204e9800998ecf8427e"

1. 초기 리소스 요청
2. ETag 값의 수신과 저장
3. 동일 리소스 재요청
4. ETag 값 비교
5. 리소스 변경 여부 판단 - 변경사안 없으면 304 not modified를 전송

반복적인 리소스 다운로드를 줄여 네트워크 트래픽을 줄일 수 있다. 변경되지 않은 리소스를 로컬에서 빠르게 읽어올 수 있어 웹 페이지 로딩 속도가 향상된다.

완벽 정리! 쿠키, 세션, 토큰, 캐시 그리고 CDN

 

쿠키

• 사용자의 컴퓨터에 저장되는 텍스트 파일이다. 쿠키를 통해 웹사이트에서 어떤 기기에 접속했는지 인식할 수 있고, 만료일을 지정할 수 있고, 만료일이 지나면 삭제된다.
• 당사자 뿐만 아니라 제 3자도 열람 가능하다.
• 탈취되어도 큰 문제가 없는 정보를 브라우저에 저장한다.(다크 모드 설정, 웹툰 목록 등)

세션 쿠키

• 만료 날짜/시간을 지정하지 않으면 세션 쿠키이다.
• 브라우저 메모리에 저장하고 세션이 끝날 때 삭제된다.
• 어떤 브라우저들은 재시작할 때 세션을 복원하여 세션 쿠키가 무기한 존재할 수 있도록 한다.

지속 쿠키

• 만료 날짜를 지정하면 지속(영속)쿠키다.
• 파일로 저장되기 때문에 종료되어도 쿠키가 남아있으며, expires 속성에 명시된 날짜에 삭제되거나 max-age 속성이 명시된 기간 이후 삭제된다.

만료 시점에 따라 구분된다.

세션

접속중인 웹 서버에 저장되는 데이터다. 쿠기보다는 상대적으로 안전하고, 브라우저를 닫거나 서버에서 세션을 삭제하면 없어진다.

로그인 여부 등 사용자와 서버의 관계가 기억되어 보존되고 있는 상태를 말한다.

로그인 유효기간이 끝날 때 까지 반복적으로 아이디와 비밀번호를 입력하지 않도록 서버로부터 인증받았음을 증명해주는 세션이란ㄴ 증서가 필요 0< 로그인에 성공하면 세션 아이디라는 데이터를 만들고 → 세션 아이디를 사용자에게 전달하고 메모리에 아이디 사본을 어떤 사용자의 것인지 적어서 보관

 

session storage

• 새 창, 새 탭의 단위로 스토리지가 생성되며 서로 데이터를 공유하지 않는다.
• 같은 탭이라도 도메인이 달면 다른 세션 스토리지가 셍성된다.
• 잠깐의 정보를 저장하기에 용이하다

local storage

• 웹 도메인당 1개씩 생성된다.
• 세션 스토리지와 다르게 새 창을 띄워도 도메인만 같으면 데이터가 공유되고 다른 도메인 로컬 스토리지에 접근이 불가하다
• 직접 로컬스토리지를 삭제하지 않으면 영구적으로 데이터 저장을 한다.(자동로그인 등에 사용)

로컬 스토리지는 데이터 영구 저장이 가능, 세션 스토리지는 브라우저 탭/윈도우가 닫히면 스토리지가 초기화

토큰

난수 형태의 문자열이다. 데이터에 접근하는 유저들에게 권한을 부여하는 카드키처럼 사용된다.

• 접근 토큰
• 보안 토큰
• 세션 토큰

세션은 공간이 한정되어 있기 떄문에 동시 접속자가 많아지면 메모리 공간이 부족해져 서버에 부하가 걸림

→ 메모리 공간을 많이 차지하는 세션 아이디 대신 토큰을 발급(위조 방지가 있는 지폐같은 유효한 토큰 발행)

발급받은 토큰을 쿠키에 저장해두고 필요할 때 마다 제시 → 요청 허가

상태를 저장하지 않는다. 서버 부하를 줄일 수 있다.

문제는 토큰은 유효기간이 끝날 때 까지 통제 불가능 → 탈취당할수 있음(만료 기간을 지정해야함)

 

결과적으로 쿠기와 캐시 모두 리소스를 저장하고 재활용하는 기술이지만, 쿠키는 사용자의 수고를 덜어주는 것에 목적을 두고 캐시는 데이터의 전송량을 줄이고 서비스 이용 속도를 높이는게 목적이다.

JWT 토큰

JWT란 무엇인가?

JWT는 json Web Token의 약자로, 일반적으로 클라이언트와 서버 사이에서 통신할 때 권한을 위해 사용되는 토큰이다.

웹 상에서 정보를 Json 형태로 주고받기 위해 표준규약에 따라 생성한 암호화된 토큰으로 복잡하고 읽을 수 없는 string 형태로 저장되어 있다.

 

JWT 토큰 구성

• 헤더 (Header) 어떠한 알고리즘으로 암호화 할 것인지, 어떠한 토큰을 사용할 것 인지에 대한 정보가 들어있다.
• 정보 (Payload) 전달하려는 정보(사용자 id나 다른 데이터들, 이것들을 클레임이라고 부른다)가 들어있다.payload에 있는 내용은 수정이 가능하여 더 많은 정보를 추가할 수 있다. 그러나 노출과 수정이 가능한 지점이기 때문에 인증이 필요한 최소한의 정보(아이디, 비밀번호 등 개인정보가 아닌 이 토큰을 가졌을 때 권한의 범위나 토큰의 발급일과 만료일자 등)만을 담아야한다.
• 서명 (Signature) 가장 중요한 부분으로 헤더와 정보를 합친 후 발급해준 서버가 지정한 secret key로 암호화 시켜 토큰을 변조하기 어렵게 만들어준다.한가지 예를 들어보자면 토큰이 발급된 후 누군가가 Payload의 정보를 수정하면 Payload에는 다른 누군가가 조작된 정보가 들어가 있지만 Signatute에는 수정되기 전의 Payload 내용을 기반으로 이미 암호화 되어있는 결과가 저장되어 있기 때문에 조작되어있는 Payload와는 다른 결과값이 나오게 된다.이러한 방식으로 비교하면 서버는 토큰이 조작되었는지 아닌지를 쉽게 알 수 있고, 다른 누군가는 조작된 토큰을 악용하기가 어려워진다.

일반 토큰 vs 클레임 토큰 기반(JWT)

• 일반 토큰 기반 인증은 토큰을 검증할 때 관련 정보들을 서버에 저장해두고 있었기 때문에 항상 DB에 접근해야만 했다.
• 세션 방식 또한 저장소에 저장해둔 session ID를 찾아와 검증하는 절차를 가져 다소 번거롭게 느껴진다.
• 클레임 토큰 기반 JWT는 사용자 인증에 필요한 모든 정보를 토큰 자체에 담고 있기 때문에 별도의 인증 저장소가 필요 없다.

REST, RESTful, RESTful API

REST란? REST API란? RESTful이란?

REST API(Restful API)란 무엇일까? 특징 6가지 - 센트빈 개발 블로그

REST란?

1. 웹의 기존 기술과 http 프로토콜을 그대로 활용하여 웹의 장점을 최대한 활용할 수 있는 아키텍쳐의 한 형식이다.
2. 네트워크상 client와 server 사이의 통신 방식 중 하나이다.

자원을 이름으로 구분하여 해당 자원의 상태를 주고받는 모든 것

자원의 표현에 의하 상태 전달

 

Rest 구성

1. 자원(Resource): URI
   • 모든 자원에 고유한 ID가 존재하고, 이 자원은 Server에 존재한다.
   • 자원을 구별하는 ID는 ‘/groups/:group_id’와 같은 HTTP URI 다.
   • Client는 URI를 이용해서 자원을 지정하고 해당 자원의 상태(정보)에 대한 조작을 Server에 요청한다.
2. 행위(Verb): HTTP Method
   • HTTP 프로토콜의 Method를 사용한다.
   • HTTP 프로토콜은 GET, POST, PUT, DELETE 와 같은 메서드를 제공한다.
3. 표현(Representation of Resource)
   • Client가 자원의 상태(정보)에 대한 조작을 요청하면 Server는 이에 적절한 응답(Representation)을 보낸다.
   • REST에서 하나의 자원은 JSON, XML, TEXT, RSS 등 여러 형태의 Representation으로 나타내어 질 수 있다.
   • JSON 혹은 XML를 통해 데이터를 주고 받는 것이 일반적이다.

특징

1. Uniform Interface(유니폼 인터페이스) - URI로 지정한 리소스에 대한 조작을 통일되고 한정적인 인터페이스로 수행하는 아키텍쳐
2. Stateless - 작업을 위해 따로 상태를 저장하지 않고 단순 처리만 함
3. Cacheable - 캐시 가능, HTTP의 기존 인프라를 그대로 활용 가능하며, 캐싱 기능 또한 적용 가능. Last Modifies 태그 혹은 ETag로 캐싱 구현 가능
4. Selft-descriptiveness(자체 표현 구조) - Rest API 메세지만 보고도 사용자가 쉽게 이해할 수 있는 자체 표현 구조를 가지고 있다.
5. Client-server 구조 - Rest 서버는 API 제공, 클라이언트는 사용자 인증이나 콘텍스트 등을 직접 관리하는 구조로 역할이 구분되어야 개발해야 할 내용이 명확하고 서로 간 의존성이 줄어든다.
6. 계층형 구조 - 다중 계층으로 구성 가능하여 보안, 로드밸런싱, 암호화 계층 등을 추가해 구조상의 유연성을 둘 수 있다.

REST API 규칙

1. URI는 정보의 자원을 표현해야 한다.
   • resource는 동사보다는 명사를, 대문자보다는 소문자를 사용한다.
   • resource의 도큐먼트 이름으로는 단수 명사를 사용해야 한다.
   • resource의 컬렉션 이름으로는 복수 명사를 사용해야 한다.
   • resource의 스토어 이름으로는 복수 명사를 사용해야 한다. ex) GET /Member/1 -> GET /members/1
2. 자원에 대한 행위는 HTTP Method(GET, PUT, POST, DELETE 등)로 표현한다.
   • URI에 HTTP Method가 들어가면 안된다. ex) GET /members/delete/1 -> DELETE /members/1
   • URI에 행위에 대한 동사 표현이 들어가면 안된다.(즉, CRUD 기능을 나타내는 것은 URI에 사용하지 않는다.) ex) GET /members/show/1 -> GET /members/1 ex) GET /members/insert/2 -> POST /members/2
   • 경로 부분 중 변하는 부분은 유일한 값으로 대체한다.(즉, :id는 하나의 특정 resource를 나타내는 고유값이다.) ex) student를 생성하는 route: POST /students ex) id=12인 student를 삭제하는 route: DELETE /students/12

Rest API 장점

• HTTP 프로토콜 인프라를 그대로 사용하여 별도 인프라 구축이 필요 없다.
• HTTP 프로토콜의 장점을 그대로 가져간다.
• HTTP 프로토콜을 따르는 모든 플랫폼에 적용 가능
• Hypermedia API 기본을 충실히 지키고 범용성을 보장
• 의도하는 바를 쉽게 파악할 수 있다.
• 여러 서비스 디자인에서 생길 수 있는 문제를 최소화
• 서버와 클라이언트 역할을 명확하게 분리

Rest API 단점

• 표준이 존재하지 않는다.
• 사용할 수 있는 메서드가 4가지 밖에 안된다.(get post put delete)
• 브라우저로 테스트를 많이 하면 Header 값 수정이 어려워 테스트에 어려움을 느낄 수 있다.
• 구형 브라우저에서 지원하지 않는 PUT, DELETE가 있다.

Restful

일반적으로 REST라는 아키텍처를 구현하는 웹 서비스를 나타내기 위해 사용되는 용어로 REST API를 제공하는 웹 서비스를 RESTFUL 하다고 한다.

• 이해하기 쉽고 사용하기 용이한 API 만드는 것
• 성능 향상 뿐만 아니라 일관적인 Convention을 통해 API의 이해도 및 호환성을 높이는 것(필수적으로 restful API를 구현할 필요는 없으며 상황에 따라 적절하게 사용한다.)

CRUD를 모두 POST로만 처리하는 API나 route에 resource, id외 정보가 들어가는 경우 Restful하지 않다.