Dev Diary.

전송 방식 설명

- 단순 전송

- 압축 전송

- 분할 전송

- 범위 전송

메시지 바디에 대한 컨텐트의 길이를 알 수 있을때 쓰는 방식이다.

압축하고 Content-Encoding 필드에 값을 넣어줘야 한다 그래야만 클라이언트가 압축을 풀 수 있다.

Transfer-Encoding : chunked 라고 하면 나눠서 보내게 된다.

5바이트 씩 먼저 받아볼 수 있다.

끝이라는 의미도 따로 표현해야한다. 용량이 큰 데이터를 한번에 보내게되면 기다려야하기 때문에

이 방법을 쓴다.

이때는 Content-Length를 보내면 안된다.

예를들어 이미지를 받는데 중간에 절반정도 받았다고 치고 끊겨버렸다.

그때 처음부터 받으면 비효율적이라 내가 받은 범위 다음부터 보내달라고 요청할 수 있다.

협상(콘첸츠 네고시에이션)

클라이언트가 선호하는 표현 요청

Accept : 클라이언트가 선호하는 미디어 타입 전달

Accept-Charset : 클라이언트가 선호하는 문자 인코딩

Accept-Encoding : 클라이언트가 선호하는 압축 인코딩

Accept-Language : 클라이언트가 선호하는 자연 언어

협상 헤더는 요청시에만 사용 

한국어 브라우저를 사용한다고 가정하고

외국 이벤트 사이트에 접속한다. (다중언어를 지원하는 서버 언어 /  언어우선순위 1 : 영어) 

클라이언트가 서버에 요청할때 Accept-Language : ko 라고 보낸다면

기본언어가 영어라도 한국어를 지원하기 때문에 Content-Language에 ko로 한국어로 응답한다.

복잡한 경우일때이다. 

다중 언어 지원 서버지만 기본이 독일어이다. 영어는 어떻게든 읽을 수 있는데 독일어는 전혀 모르기 때문에

영어를 원하는 상황이지만 독일어로 응답한다. 이런 경우를 위해 우선순위라는 것이 필요하다.

협상과 우선순위1

Quality Values(q)

- Quality Values(q) 값 사용

- 0~1, 클수록 높은 우선순위

- 생략하면 1

- Accept-Language : ko-KR,ko;q=0.9,en-US;q=0.8,en;q=0.7

  1. ko-KR;q=1(생략)

  2. ko;q=0.9

  3. en-US;q=0.8

  4. en;q=0.7

협상과 우선순위2

Quality Values(q)

- 구체적인 것이 우선이다.

- Accept: text/*, text/plain, text/plain;format=flowed, */*

  1. text/plain;format=flowed

  2. text/plain

  3. text/*

   4. */*

협상과 우선순위3

Quality Values(q)

- 구체적인 것을 기준으로 미디어 타입을 맞춘다.

- Accept : text/*q=0.3, text/html;q=0.7, text/html;level=1, text/html;level=2;q=0.4, */*;q=0.5

표현 

Content-Type : 표현 데이터의 형식

Content-Encoding : 표현 데이터의 압축 방식

Content-Language : 표현 데이터의 자연 언어

Content-Length : 표현 데이터의 길이 (명확하게 쪼개면 페이로드 헤더라고 해야함)

표현 헤더는 전송, 응답 둘다 사용

Content-Type

표현 데이터의 형식 설명

- 미디어 타입, 문자 인코딩

- 예) text/html; charset=utf-8

       application/json

       image/png

Content-Encoding

표현 데이터 인코딩

- 표현 데이터를 압축하기 위해 사용

- 데이터를 전달하는 곳에서 압축 후 인코딩 헤더 추가

- 데이터를 읽는 쪽에서 인코딩 헤더의 정보로 압축 해제

- 예) gzip, deflate, identity

Content-Language

표현 데이터의 자연 언어

- 표현 데이터의 자연 언어를 표현

- 예) ko, en, en-US

Content-Length

표현 데이터의 길이

- 바이트 단위

- Transfer-Encoding(전송 코딩)을 사용하면 Content-Length를 사용하면 안됨

header-filed =

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

field-name은 대소문자 구문 없음

HTTP 헤더

용도 

-HTTP 전송에 필요한 모든 부가정보

  예) 메시지 바디의 내용, 메시지 바디의 크기, 압축, 인증, 요청 클라이언트, 서버 정보, 캐시 관리 정보

-표준 헤더가 너무 많음

-필요시 임의의 해더 추가 가능

HTTP 헤더

분류 - RFC2616(과거)

- General 헤더 : 메시지 전체에 적용되는 정보

- Request 헤더 : 요청 정보

- Response 헤더 : 응답 정보

- Entity 헤더 : 엔티티 바디 정보 (메시지 바디와 관련된 정보)

HTTP BODY

message body - RFC2616(과거)

- 메시지 본문은 엔티티 본문을 전달하는데 사용

- 엔티티 본문은 요청이나 응답에서 전달할 실제 데이터

- 엔티티 헤더는 엔티티 본문의 데이터를 해석할 수 있는 정보 제공

->

스펙이 바뀜 2014년 RFC7230~7235 등장

RFC723x 변화

- 엔티티 -> 표현

- 표현 = 표현 메타데이터 + 표현 데이터

HTTP BODY

message body - RFC7230(최신)

- 메시지 본문을 통해 표현 데이터 전달

- 메시지 본문 = 페이로드

- 표현은 요청이나 응답에서 전달할 실제 데이터

- 표현 헤더는 표현 데이터를 해석할 수 있는 정보 제공

4xx(Client Error)

클라이언트 오류 

- 클라이언트의 요청에 잘못된 문법등으로 서버가 요청을 수행할 수 없음

- 오류의 원인이 클라이언트에 있음

- 중요! 클라이언트가 이미 잘못된 요청, 데이터를 보내고 있기 때문에, 똑같은 재시도가 실패함

400 Bad Request

클라이언트가 잘못된 요청을 해서 서버가 요청을 처리할 수 없음

- 요청 구문, 메시지 등등 오류

- 클라이언트는 요청 내용을 다시 검토하고, 보내야함

예) 요청 파라미터가 잘못되거나, API 스펙이 맞지 않을때

401 Unauthorized

클라이언트가 해당 리소스에 대한 인증이 필요함

- 인증 되지 않음

- 401 오류 발생시 응답에 WWW-Authenticate 헤더와 함께 인증 방법을 설명

403 Forbidden

서버가 요청을 이해했지만 승인을 거부함

- 주로 인증 자격 증명은 있지만, 접근 권한이 불충분한 경우

- 어드민 등급이 아닌 사용자가 로그인은 했지만, 어드민 등급의 리소스에 접근하는 경우

404 Not Found

요청 리소스를 찾을 수 없음

- 요청 리소스가 서버에 없음

- 또는 클라이언트가 권한이 부족한 리소스에 접근할 때 해당 리소스를 숨기고 싶을 때

5xx (Server Error)

서버 오류

- 서버 문제로 오류 발생

- 서버에 문제가 있기 때문에 재시도 하면 성공할 수도 있음(복구가 되거나 등등)

500 Internal Server Error 

서버 문제로 오류 발생, 애매하면 500 오류

- 서버 내부 문제로 오류 발생

- 애매하면 500 오류

503 Service Unavailable

서비스 이용 불가

- 서버가 일시적인 과부하 또는 예정된 작업으로 잠시 요청을 처리할 수 없음

- Retry-After 헤더 필드로 얼마뒤에 복구되는지 보낼 수도 있음

일시적인 리다이렉션

302, 307, 303 

-리소스의 URI가 일시적으로 변경

-따라서 검색 엔진 등에서 URL을 변경하면 안됨

302 Found

 -리다이렉트시 요청 메서드가 GET으로 변하고, 본문이 제거될 수 있음

307 Temporary Redirect

 -302와 기능은 같음

 -리다이렉트시 요청 메서드와 본문 유지

303 See Other

 -302와 기능은 같음

 -리다이렉트시 요청 메서드가 GET으로 변경

PRG: Post/Redirect/Get

일시적인 리다이렉션 - 예시

- POST로 주문 후에 웹 브라우저를 새로고침하면?

- 새로고침은 다시 요청

- 중복 주문이 될 수 있다.

/order 폼에다가 데이터를 입력후 POST 메서드로 전송한다. 

서버는 주문데이터를 저장하고 200 OK 보낸다.

혹시 새로고침을 누르게 되면 또다시 서버는 주문 데이터를 저장하게된다.

주문완료 200 OK를 보낸다. 새로고침을 할 때마다 주문을 여러개 하게 된다.

이러한 문제를 해결하기 위해서 PRG를 사용한다.

PRG: Post/Redirect/Get

일시적인 리다이렉션 - 예시

 - POST로 주문후에 새로 고침으로 인한 중복 주문 방지

 - POST로 주문후에 주문 결과 화면을 GET 메서드로 리다이렉트

 - 새로고침해도 결과 화면을 GET으로 조회

 - 중복 주문 대신에 결과 화면만 GET으로 다시 요청

POST 메서드로 폼에 데이터를 넣고 요청을함

데이터베이스에 상품이 쌓인다.

이때 응답을 302 Found와 Location 정보를 준다. /order-result/19

클라이언트는 302코드를 보고 리다이렉트를한다. GET메서드 사용

서버는 주문 결과를 보내고 (200 OK)

이렇게되면 새로고침을 아무리한다고 해도 GET메서드 덕분에 다시 결과를 보게된다.

PRG 이후 리다이렉트

 - URL이 이미 POST -> GET으로 리다이렉트 됨

 - 새로고침해도 GET으로 결과 화면만 조회

그래서 뭘 써야할까?

302, 307, 303

정리

302 Found -> GET으로 변할 수 있음

307 Temporary Redirect -> 메서드가 변하면 안됨

303 See Other ->메서드가 GET으로 변경

역사

 - 처음 302 스펙의 의도는 HTTP 메서드를 유지하는 것

 - 그런데 웹 브라우저들이 대부분 GET으로 바꾸어버림

 - 그래서 모호한 302를 대신하는 명확한 307, 303이 등장

현실

 - 307, 303을 권장하지만 현실적으로 이미 많은 애플리케이션 라이브러리들이 302를 기본값으로 사용

 - 자동 리다이렉션시에 GET으로 변해도 되면 302를 사용해도 큰 문제 없음

기타 리다이렉션

300, 304

300 Multiple Choices : 안쓴다.

304 Not Modified

 - 캐시를 목적으로 사용

 - 클라이언트에게 리소스가 수정되지 않았음을 알려준다. 따라서 클라이언트는 로컬PC에 저장된 캐시를 재사용한다.

 - 304 응답은 응답에 메시지 바디를 포함하면 안된다.

 - 조건부 GET, HEAD 요청시 사용 

3xx (Redirection)

요청을 완료하기 위해 유저 에이전트의 추가 조치 필요

300 Multiple Choices

301 Moved Permanently

302 Found

303 See Other

304 Not Modified

307 Temporary Redirect

308 Permanent Redirect 

리다이렉션 이해

 웹 브라우저는 3xx 응답의 결과에 Location 헤더가 있으면, Location 위치로 자동 이동

예를 들어 /event 이벤트 페이지를 하나 만들고 더 이상 쓰지 않게되어

/new-event라는 새로운 이벤트 페이지를 만들었다 

기존에 사용하던 사용자들은 북마크 등등을 통해 /event로 접속을 한다.(GET)

서버에 입장에서는 더 이상 안쓰는 페이지이기때문에 Location에 /new-event를 알려준다.(301 코드)

이제 클라이언트 입장에서는 3xx대 응답, Location필드를 보고 웹 브라우저가 스스로 /new-event로 다시 요청을한다.

서버는 200 OK를 보낸다.

사용자 입장에서는 너무 빨라 인식하기 어렵다.

종류

영구 리다이렉션 - 특정 리소스의 URI가 영구적으로 이동 

  예) /members -> /users

       /event -> /new-event

일시 리다이렉션 - 일시적인 변경

  -주문 완료 후 주문 내역 화면으로 이동

  -PRG : Post/Redirect/Get

특수 리다이렉션

 -결과 대신 캐시를 사용

영구 리다이렉션

301, 308

리소스의 URI가 영구적으로 이동

원래의 URI를 사용하지 않고, 검색 엔진 등에서도 변경 인지

301 Moved Permanently

  - 리다이렉트시 요청 메서드가 GET으로 변하고, 본문이 제거될 수 있음

308 Permanent Redirect

  - 301과 기능은 같은

  - 리다이렉트시 요청 메서드와 본문 유지

/event 라고 POST 요청을 보낸다 (바디에 데이터 포함)

서버는 /event를 이제 쓰지 않으니 301요청을 Location에 /new-event를 보낸다.

클라이언트에서 URL을 자동으로 바꾼다. 이때 요청 메서드가 GET으로 변경된다.

등록을 하기를 원해서 POST로 보냈지만 GET으로 날아가며 메시지 바디부분에 데이터가 사라진다.

(새로 데이터를 입력해야하는 화면이 나오게된다.)

과정은 301과 동일하지만 POST를 유지 하며 자동 리다이렉트가 되며

데이터가 등록이 될 것이다. 설명을 위해서 예를든것이지 실무에서는 이런 상황에서 308을 쓰지 않는다.

왜냐하면 데이터가 다 바뀌어 버리기 때문이다. 사실 영구 리다이렉션 사실 영구 리다이렉션보다 일시적인 리다이렉션을 많이 사용한다.

2xx(Successful)

클라이언트의 요청을 성공적으로 처리

200 OK

 - 요청 성공

201 Created

 - 요청 성공해서 새로운 리소스가 생성됨

 - 신규 자원 등록 시 POST의 경우에 서버에서 자원을 생성하고 URI관리도 서버에서 하는데 이때

   생성된 리소스는 응답의 Location 헤더 필드로 식별한다. 

202 Accepted

 - 요청이 접수되었으나 처리가 완료되지 않았음

 - 배치 처리 같은 곳에서 사용

 - 예) 요청 접수 후 1시간 뒤에 배치 프로세스가 요청을 처리함

204 No Content

 - 서버가 요청을 성공적으로 수행했지만, 응답 페이로드 본문에 보낼 데이터가 없음

 - 예) 웹 문서 편집기에서 save 버튼

 - save 버튼의 결과로 아무 내용이 없어도 된다.

 - save 버튼을 눌러도 같은 화면을 유지해야 한다.

 - 결과 내용이 없어도 204메시지 만으로 성공을 인식할 수 있다.

회원 관리 시스템

API 설계 - POST 기반 등록

회원 목록 /members -> GET

회원 등록 /members -> POST

회원 조회 /members/{id} -> GET

회원 수정 /members/{id} -> PATCH,PUT,POST

회원 삭제 /members/{id} -> DELETE

-POST 신규 자원 등록 특징

  클라이언트는 등록될 리소스의 URI를 모른다.

    회원 등록 /members -> POST  

  POST /members

  서버가 새로 등록된 리소스 URI를 생성해준다.

    HTTP/1.1 201 Created

    Location: /members/100

  컬렉션

    서버가 관리하는 리소스 디렉토리

    서버가 리소스의 URI를 생성하고 관리

    여기서 컬렉션은 /members

파일 관리 시스템

API 설계 - PUT 기반 등록

파일 목록 /files -> GET

파일 조회 /files/{filename} -> GET

파일 등록 /files/{filename} -> PUT

파일 삭제 /files/{filename} -> DELETE

파일 대량 등록 /files -> POST

PUT - 신규 자원 등록 특징

  클라이언트가 리소스 URI를 알고 있어야 한다.(파일 등록 시 파일이름을 넣어줘야 한다.)

    파일 등록 /files/{filename} -> PUT

    PIUT /files/star.ipg

  클라이언트가 직접 리소스의 URI를 지정한다.

  스토어

    클라이언트가 관리하는 리소스 저장소

    클라이언트가 리소스의 URI를 알고 관리

    여기서 스토어는 /files

HTML FORM 사용

HTML FORM은 GET, POST만 지원

AJAX 같은 기술을 사용하여 해결 가능 -> 회원 API 참고

여기서는 순수 HTML, HTML FORM 이야기

GET, POST만 지원하므로 제약이 있음

회원 목록     /members -> GET

회원 등록 폼 /members/new -> GET

회원 등록     /members/new, /members -> POST

회원 조회     /members/{id} -> GET

회원 수정 폼 /members/{id}/edit -> GET

회원 수정     /members/{id}/edit, /members/{id} -> POST

회원 삭제     /members/{id}/delete -> POST

컨트롤 URI

  GET, POST만 지원하므로 제약이 있음

  이런 제약을 해결하기 위해 동사로 된 리소스 경로 사용

  POST의 /new, /edit, /delete가 컨트롤URI

  HTTP 메서드로 해결하기 애매한 경우 사용

데이터 전달 방식은 크게 2가지

쿼리 파라미터를 통한 데이터 전송

GET

주로 정렬 필터(검색어)

메시지 바디를 통한 데이터 전송

POST, PUT, PATCH

회원 가입, 상품 주문, 리소스 등록, 리소스 변경

4가지 상황

정적 데이터 조회

- 이미지, 정적 텍스트 문서

- 조회는 GET 사용

- 정적 데이터는 일반적을 쿼리 파라미터 없이 리소스 경로로 단순하게 조회가능

동적 데이터 조회

- 주로 검색, 게시판 목록에서 정렬 필터(검색어)

- 조회 조건을 줄여주는 필터, 조회 결과를 정렬하는 정렬 조건에 주로 사용

- 조회는 GET 사용

- GET은 쿼리 파라미터 사용해서 데이터를 전달 

HTML Form 데이터 전송

-HTML Form submit시 POST 전송

  예) 회원가입, 상품 주문, 데이터 변경

-Content-Type : application/x-www-form-urlencoded 사용

  form의 내용을 메시지 바디를 통해서 전송(key=value, 쿼리 파라미터 형식)

  전송 데이터를 url encoding 처리

-HTML Form은 GET 전송도 가능

-Content-Type : multipart/form-data

  파일 업로드 같은 바이너리 데이터 전송시 사용

  다른 종류의 여러 파일과 폼의 내용을 함께 전송 가능

-참고: HTML Form전송은 GET, POST만 지원

HTML API 데이터 전송

-서버 to 서버

  백엔드 시스템 통신

-앱 클라이언트

  아이폰, 안드로이드

-웹 클라이언트

  HTML 에서 Form 전송 대신 자바 스크립트를 통한 통신에 사용(AJAX)

  예) React, VueJs 같은 웹 클라이언트와 API 통신

-POST, PUT, PATCH : 메시지 바디를 통해 데이터 전송

-GET : 조회, 쿼리 파라미터로 데이터 전달

-Content-Type : application/json을 주로 사용

  TEXT, XML, JSON 등등