[Spring 입문] #05 HTTP 2

1️⃣ HTTP METHOD 속성

- 안전성(Safe), 멱등성(Idempotent), 캐시가능성(Cacheable)

- 우리가 주의해서 보아야할 부분은 GET, POST, PUT, DELETE, PATCH 이다.

1. 안전성(Safe)

1) GET 메소드(조회)는 안전 : 저장된 데이터를 변환하지 않는다.

2) POST, DELETE, PUT, PATCH 안전 X : 데이터를 생성, 수정, 삭제한다.

 

2. 멱등성(Idempotent)

- 한번을 호출하거나 수천번을 호출하거나 항상 결과는 같다.

1) GET : 같은 결과가 계속 조회된다.

2) PUT : 수정해서 대체된 후의 결과는 계속 같다.

- 덮어쓰기와 같다고 생각하면 된다. 기존의 값을 삭제하고 새로운 값드로 대체하기 때문에 매번 결과가 같게 된다.

3) DELETE : 같은 요청을 여러번해도 삭제된 결과는 같다.

4) POST : 멱등성을 보장하지 않는다. 

- GET, PUT, DELETE 는 모두 같은 결과를 준다. 하지만 왜 POST 는 멱등성을 보장하지 않는가?

- POST 라는 메서드는 새로운 데이터를 추가하는 메서드이다.

- 이때 같은 게시물을 여러번 시도를 해보자. 먼저 처음 게시물을 만들 경우

- 우리는 id 가 1이라는 게시물이 등록될 것이다.

- 이것을 n 번 반복한다면 ? 매번 새로운 고유한 id 값이 지정될 것이다.

- 새로운 리소스가 생성된다는 말이다. 같은 요청을 여러 번 보내도 항상 같은 결과가 나온다고 보장할 수 없다. 중복요청이 예상치 못한 결과를 초래할 수도 있을 것이다.

- 그래서, POST 의 경우 멱등성을 보장하지 않는다는 것이다 !

5) PATCH : 멱등성을 보장하지 않는다. 

- POST 와 마찬가지로 PATCH 도 멱등성을 보장하지 않는다. 

- PUT 은 덮어 씌우는 것이라면, PATCH는 일부만 변경하는 것이다. 

- 누적 변경이나 추가/삭제를 포함하면 멱등하지 않다.

- 존재하는 값만 변경 하는 경우도 있지만, 없는 값이면 새로 추가하는 방식으로 동작할 수도 있다. => 필드가 없을 때는 데이터가 생성될 수도 있고, 무시도리 수도 있다는 것 ( 멱등하지 않다는 것)

- 그리고, 특정 연산을 수행할 수 있는데 연산결과가 매번 달라져 멱등하지 않을 수 있다.

5) 요청이 실패한 경우 재시도 하기위해 필요하다.

- 항상 결과가 같다면 마음껏 재시도 해도된다.

- 만약 멱등하지 않다면, 중복 요청을 보내서는 안된다.

- 복구 매커니즘에 사용한다. - ex) 요청 실패시 서버에서 자동으로 재시도

 

3. 캐시가능성(Cacheable)

- 재사용을 위해 요청에 대한 응답을 저장할 수 있는가?

1) GET, HEAD, POST 메소드는 캐시가 가능하다.

2) 일반적으로 GET, HEAD 정도만 캐시로 사용한다.

ex) 변경 가능성이 적은 정적자원(HTML, CSS, IMAGE, JS 등)을 주로 캐싱한다.

캐시(Cache)란?
클라이언트가 서버에 한번 요청했던 데이터에 대해서 매번 요청할 때 마다 다시 전송할 필요가 없도록 웹 브라우저가 임시적으로 데이터를 보관하고 있는 장소이다.

 

2️⃣ HTTP 상태 코드

- HTTP Response Message의 Start LIne에 속해있던 Status Code에 대해 알아보자.

1xx	정보	요청수신 후 처리 중인 상태. 잘 사용하지 않음.	-	-
2xx	성공	정상 처리 완료된 상태	200 OK	요청성공
			201 Created	새로운 리소스 생성
			202 Accepted	요청이 수신 되었으나 처리가 완료 되지 않음 주로 Batch 처리에 사용
			204 No Content	요청은 성공했지만, 응답 데이터가 없음
3xx	영구 리다이렉션	요청을 완료하려면 추가 행동이 필요한 상태 3xx 응답 + Location HTTP Header가 있으면 Location 위치로 리다이렉트 한다.	301 Moved Permanently	요청 메서드가 GET으로 변하고 본문이 제거될 수 있다.
			308 Permanent Redirect	리다이렉트시 요청 메서드와 본문이 유지된다.
	일시 리다이렉션		302 Found	일시 다이렉션 요청 메서드가 GET으로 변할 수 있다. 모호해서 명확한 303, 307이 등장하게 되었다. 이미 사용하고 있는곳이 많다 GET으로 변해도 상관없다면 사용해도 무방하다.
			303 See Other	요청 메서드가 GET으로 변경된다.
			307 Temporary Redirect	리다이렉트시 요청 메서드와 본문이 유지된다.
	기타 리다이렉션		304 Not Modified	캐시 목적으로 사용된다. 리소스가 수정되지 않았다는 뜻, 클라이언트가 캐시된 데이터를 조회하도록 유도한다. 응답에 바디가 있으면 안된다.
4xx	클라이언트 에러	클라이언트측 오류, 잘못된 문법 등으로 서버가 요청을 수행할 수 없다. 클라이언트의 요청이 잘못되었기 때문에, 같은 요청의 재시도는 실패한다.	400 Bad Request	클라이언트가 HTTP 요청 내용을 수정 후 보내야 한다. ex) GET 메소드로 만들어진 API인데 POST로 보낸다? ex) API 스텍과 불일치 ( 문자를 숫자로 )
			401 Unauthorized	클라이언트가 리소스에 대한 인증(Authentication)이 필요하다. 응답에 `WWW-Authenticate` 헤더와 함께 인증 방법을 설명한다. ex) 로그인
			403 Forbidden	서버가 요청을 받았지만 승인 거부 주로 인가(Authorization) 관련문제 ex) 일반 유저, 관리자
			404 Not Found	요청한 리소스가 서버에 없다. 이를 이용하여 리소스를 숨겨놓기도 한다. 있지만 없는척 가능
5xx	서버 에러	서버 오류, 요청은 정상이지만 서버가 처리하지 못함 재시도하면 성공할 수 있다. 실제 서버에서 문제가 발생한 경우 5xx Error이기 때문에 발생하지 않는것이 최선이다. ex) 서버가 일정시간 다운되었다가 다시 살아난 경우	500 Internal Server Error	대부분 500으로 처리한다.
			503 Service Unavailable	서비스 이용 불가 Retry-After Header를 사용하면 얼마뒤에 복구되는지 응답할 수 있다.

1) 영구 리다이렉션

- URL이 영구적으로 변경된 경우, 기존 URL을 사용하지 않는다.

2) 일시 리다이렉션

- URI가 일시적으로 변경된 경우

- ex) 게시글 작성 후 게시글 목록 페이지로 이동, PRG 패턴

+) PRG(Post, Redirect, Get) 패턴이란?

- 게시글 작성(Post) → 응답(Redirect) → 리다이렉트 요청(Get)

+) PRG 패턴을 적용 한다면?

- 새로고침을 하면 GET 요청을 한다.

+) PRG 패턴을 적용하지 않는다면?

- 새로고침을 하게되면 요청이 중복으로 처리된다.

3) 기타 리다이렉션

- 캐시를 활용할 것인지에 대한 여부

 

3️⃣ HTTP API 설계

1. HTTP API 설계 방법

1) HTTP API는 설계시 항상 리소스 식별을 기준으로 삼아야한다.

2) URI에 들어갈 리소스는 단수 형태가 아닌 복수 형태로 사용을 권장한다. board → boards

3) URL에 동사를 사용하지 않는다.

4) HTTP Method의 역할을 URL에 포함하지 않는다.

 

2. HTTP API 설계

1) 게시글 생성

• POST
• /boards
• 성공시 상태코드 2xx
• 실패시 4xx (클라이언트 문제) OR 5xx (서버 문제)

2) 게시글 1개 조회

• GET
• /boards/{id}
• 성공시 상태코드 2xx
• 실패시 4xx (클라이언트 문제) OR 5xx (서버 문제)

3) 게시글 목록 조회

• GET
• /boards
• 성공시 상태코드 2xx
• 실패시 4xx (클라이언트 문제) OR 5xx (서버 문제)

4) 게시글 수정

• PUT or PATCH
• /boards/{id}
• 성공시 상태코드 2xx
• 실패시 4xx (클라이언트 문제) OR 5xx (서버 문제)

5) 게시글 삭제

• DELETE
• /boards/{id}
• 성공시 상태코드 2xx
• 실패시 4xx (클라이언트 문제) OR 5xx (서버 문제)

 

4️⃣ HTTP Header

이전에 포스팅한 글에서 HTTP Message 에 대해서 한번 다룬 적이 있다. 다시 리마인드를 하자면 HTTP Message 는 이렇게 4가지 부분으로 구성되어 있다.

여기서 Header 만 조금 더 설명하겠다 !

- field-name: OWS field-value OWS (OWS : 띄어쓰기 허용)

- field-name은 대소문자 구분을 하지 않는다.

- HTTP 전송에 필요한 모든 부가정보를 표현할 수 있다.

- 임의의 Header를 추가할 수 있다. 단, 서버가 값을 알고있어야 함

- 텍스트 (plain text)로 이루어져 있다.

- 각각의 헤더는 하나의 줄로 구분된다.

 

5️⃣HTTP Header 모음집

1. 표현 헤더

• 실제 데이터를 전송할 때는 특정 형식으로 변환하여 보내게된다.
• 리소스에 대한 표현 정보(어떤 데이터 형식으로 보낼지)를 나타낸다.
• 요청, 응답에 모두 사용되는 Header이다.

Content-Type : 형식	전송할 데이터의 미디어 타입, 문자 인코딩을 나타낸다.
Content-Encoding : 압축 방식	데이터를 압축 후 Encoding 헤더를 추가하면, 읽는 쪽에서 해당 정보로 압축을 해제한다.
Content-Language : 언어	데이터의 언어를 표현한다.
Content-Length : 길이	실제로는 표현 헤더가 아닌, 페이로드(Payload) 헤더이다. byte 단위로 나타낸다.

 

2. Content Negotiation

• 클라이언트가 선호하는 표현을 요청한다.
• 요청시에만 사용되는 Header이다.
• 우선 순위가 존재한다.
  • Quality Values 줄여서 q 값을 사용한다.
  • 0 ~ 1 사이의 값이 존재하며 1에 가까울수록 우선순위가 높다.
• q가 생략되었다면 선언된 순서대로 우선순위를 가진다.
• 구체적으로 선언된 것이 우선순위가 높다.

Accept	선호하는 미디어 타입
Accept-Charset	선호하는 문자 인코딩
Accept-Encoding	선호하는 압축 인코딩
Accept-Language	선호하는 언어

 

3. 일반 정보

- 단순한 정보들을 나타내는 Header 이다.

From	클라이언트 이메일 정보	잘 사용하지 않
Referer	현재 요청된 페이지의 이전 웹 페이지 주소 유입 경로 파악 가능	요청시 사용
User-Agent	라이언트 애플리케이션 정보(PC, Mobile 브라우저) 어떤 환경에서 주로 접속하는지 통계 어떤 종류의 환경에서 장애가 발생하는지 파악 가능	요청시 사용
Server	Server : 요청을 처리하는 ORIGIN 서버의 Software 정보	응답에서 사용
Date	HTTP 요청이 발생한 날짜와 시간	응답에서 사용

 

4. 특별정보

Host	요청한 도메인 정보 필수적으로 포함해야하는 Header 이다.	요청시 사용
Location	생성된 리소스 URI, 리다이렉트 주소 응답코드 3xx와 함께 응답되면 리다이렉트 주소이다.	응답코드 201(Created) 와 함께 응답되며 생성된 리소스의 UI
Allow	허용 가능한 HTTP Method	405 (Method Not Allowed)와 함께 응답
Retry-After	다음 요청까지 대기 해야하는 시간 503 (Service Unavailable)와 함께 서비스가 언제까지 사용이 불가한지 알려준다. 초단위, 날짜단위 모두 표현이 가능하다.

 

5. 인증

Authorization	클라이언트 인증 정보 선택한 인증 방법에 따라 Value를 작성한다
WWW-Authenticate	리소스에 필요한 인증 방법 401 (Unauthorized) 응답과 함께 사용된다.

 

6. Cookie

• HTTP는 Stateless 특성을 가지고 있어서 상태를 매번 보내주어야 한다.
• Cookie를 사용하여 모든 요청마다 상태를 전달한다.
• 사용자 세션 관리, 광고 정보 트래킹에 많이 사용된다.

Set-Cookie	서버에서 응답시 클라이언트로 Cookie 값 전달 만료기간(expire, max-age), 사용될 위치(domain, path)를 설정할 수 있다. 주의 > 항상 서버에 전달되니 최소한의 정보만 사용하여 트래픽을 최적화 시켜야 하며, 탈취 당하기 쉬우니 보안에 민감한 개인정보 등은 저장하지 않는다.
Cookie	클라이언트가 서버에서 받은 쿠키를 Cookie 헤더를 통해 전송한다.
Secure	해당 헤더가 적용되면 https인 경우에만 쿠키를 전송한다. 기본적으로 http, https 구분하지 않고 쿠키를 전송한다. HTTP + Secure 가 HTTPS 이다.
HttpOnly	http 전송에만 사용한다. 자바스크립트에서 쿠키를 접근하지 못하게 만든다.
SameSite	쿠키에 설정된 도메인이 같은 경우만 쿠키를 전송한다.

 

7. Cache

• 캐시가 없다면 같은 요청에 대한 응답 데이터가 같아도 매번 데이터를 새로 다운로드 받는다.
• 새로 다운로드 받는만큼 속도가 느려지고, 비용이 발생한다.

Cache-Control 응답시 사용하는 헤더	max-age	캐시 유효 시간(초) 캐시 유효 시간이 지나면 다시 서버를 통해 데이터를 응답받고 캐시를 갱신한다.
	no-cache	캐시 가능한 데이터지만, 서버에 검증하고 사용해야 한다.
	no-store	보안에 민감한 데이터, 캐시하지 않는다.
if-modified-since 요청시 사용하는 헤더	캐시로 저장된 데이터 최종 수정일
Last-Modified 응답시 사용하는 헤더	데이터가 마지막으로 수정된 시간 if-modified-since 요청이 오면 응답한다. 304 (Not Modified) 상태코드와 함께 응답되면 수정되지 않았다는 의미 > HTTP Message Body가 존재하지 않는다. 캐시 사용
ETag 요청시 사용하는 헤더	캐시용 데이터에 날짜, 시간이 아닌 이름을 지정한다. if-modified-since + Last-Modified 방식은 수정된 데이터가 같거나 캐시가 불필요한 경우를 구분하지 못한다.

 

6️⃣ Restful API

Restful API 란 ?
REST를 잘 준수하는 API로 HTTP 프로토콜을 사용하여 클라이언트와 서버 간의 통신을 통해 자원(Resource)을 관리한다. 자원은 고유한 URI로 식별되며, HTTP 메서드(GET, POST, PUT, DELETE 등)를 통해 다양한 작업을 수행하며 요청과 응답은 일반적으로 JSON 또는 XML 형식으로 이루어진다.

→ REST 기반으로 서비스 API를 구현한 것, HTTP API를 잘 설계하는 규칙이라고 정리할 수 있다.

1. REST(Representational State Transfer)란?

- 자원(Resource)을 이름(Name)으로 구분하여 해당 자원의 상태(정보)를 주고받는 것을 의미한다.

- URI를 통해 자원(Resource)을 명시하고, HTTP Method(POST, GET, PUT, DELETE,PATCH 등)를 통해 해당 자원에 대한 CRUD Operation을 적용하는 것을 REST라 칭한다.

 

2. RestAPI 문서

- 해당 사이트는 RestAPI 문서이다.

REST API URI Naming Conventions and Best Practices

REST API URI Naming Conventions and Best Practices

 

1) 리소스는 명사를 사용해야 한다.

2) 단수가 아닌 복수 형태를 사용해야 한다.

3) 만약, REST만으로 해결하기 어려운 경우라면 동사를 허용한다.

4) 자원의 계층 관계를 슬래시(/)로 표현한다.

5) 마지막 문자에는 슬래시(/)가 있으면 안된다.

6) 언더바(_)가 아닌 하이픈(-)을 사용해야 한다.

7) 소문자를 사용해야 한다.

8) URI에 파일 확장자를 포함하면 안된다.

9) CRUD 함수명은 사용하지 않고, HTTP Method를 활용해야 한다.

10) 정렬, 필터링, 페이징은 신규 API를 만드는것이 아닌 Query Parameter를 사용해야 한다.