<div id="readability-page-1" class="page"><div><h2 id="http-메서드">HTTP 메서드</h2>
<h3 id="api-url">API URL</h3>
1. 설계
<ul>
<li>가장 중요한 것은 리소스 식별</li>
<li>리소스의 의미<ul>
<li>'회원'이라는 개념 자체가 리소스</li>
<li>회원이라는 리소스만 식별하면 된다.</li>
<li>회원 리소스를 URI에 맵핑</li>
</ul></li>
<li>리소스와 행위를 분리<ul>
<li>리소스는 명사, 행위는 동사</li>
<li>메서드로 구분한다</li>
</ul></li>
</ul>
2. GET, POST
<ul>
<li>GET<ul>
<li>리소스 조회, 서버에 전달하고 싶은 데이터를 쿼리를 통해 전달</li>
<li>바디를 사용할 수 있지만 권장하지 않음</li>
</ul></li>
<li>POST<ul>
<li>요청 데이터 처리</li>
<li>메시지 바디를 통해 서버로 요청 데이터 전달</li>
</ul></li>
<li>POST는 요청 데이터를 어떻게 처리할까? <ul>
<li>데이터 블록 처리 프로세스 제공</li>
<li>게시판 글쓰기 등</li>
<li>서버가 아직 식별하지 않은 새 리소스 생성</li>
<li>핵심은 POST 요청이 오면 요청마다 어떻게 처리할지 정하는 것!</li>
<li>단순히 데이터 생성, 변경이 아니라 프로세스를 처리하는 것이다</li>
</ul></li>
</ul>
3. PUT, PATCH, DELETE
<ul>
<li>PUT<ul>
<li>리소스를 대체</li>
<li>리소스가 없으면 완전히 대체, 있으면 생성</li>
<li>클라이언트가 리소스를 식별(클라가 리소스 위치를 알고 있음)</li>
<li>요청, 응답의 스펙이 다를 경우 리소스를 덮어버림 (PUT은 리소스 수정이 아님)</li>
</ul></li>
<li>PATCH<ul>
<li>리소스 부분 변경</li>
</ul></li>
</ul>
4. HTTP 메서드 속성
<ul>
<li>안전</li>
<li>멱등<ul>
<li>한 번이든 백 번이든 결과가 똑같다.</li>
<li>POST는 멱등이 아님</li>
<li>재요청 중 다른 곳에서 리소스 바뀐 건 고려하지 않음</li>
</ul></li>
<li>캐시가능<ul>
<li>응답 결과를 캐시 사용가능 -&gt; GET만</li>
</ul></li>
</ul>
5. HTTP 메서드 활용
<ul>
<li>정적 데이터 조회</li>
<li>동적 데이터 조회 <ul>
<li>쿼리 파라미터로 조회</li>
</ul></li>
<li>HTML Form 전송<ul>
<li>웹 브라우저가 Form을 읽어서 HTTP 메시지를 생성해줌.</li>
</ul></li>
<li>멀티파트 전송<ul>
<li>파일 업로드는 바이너리 데이터 </li>
</ul></li>
<li>HTTP API 전송<ul>
<li>서버 to 서버</li>
<li>웹 클라이언트에서 ajax로 통신</li>
</ul></li>
</ul>
5. HTTP API 설계 예시 
<img src="https://velog.velcdn.com/images/dongha1992/post/319e41be-c71e-4b55-a638-fe5c88d74206/image.png">
6. HTTP 상태 코드
<ul>
<li>2XX <ul>
<li>201 : created, 요청 성공 후 새로운 리소스 성공</li>
<li>202 : 요청 접수 되어있지만 수행 안됨 </li>
<li>204 : 요청 성공. 근데 응답값은 없음</li>
</ul></li>
<li>3xx<ul>
<li>리다이렉션: 웹 브라우저는 3xx 응답 결과에 Location 헤더가 있으면 Location 위치로 자동 이동</li>
<li>일시적 리다이렉션 : POST로 주문 후 웹 브라우저 새로고침, 새로고침은 다시 요청 -&gt; 중복요청임</li>
</ul></li>
<li>4xx<ul>
<li>401: 인증이 되지 않음. 인증(로그인), 인가(권한부여)</li>
</ul></li>
</ul>
<h3 id="헤더">헤더</h3>
1. HTTP 헤더
<ul>
<li>표현<ul>
<li>Content-Type: 미디어 타입, 문자 인코딩 등</li>
<li>Content-Encoding: 표현데이터 압축, 데이터 읽는 쪽에서 해제 </li>
<li>Content-Language: 표현데이터의 자연 언어 표현</li>
</ul></li>
<li>협상<ul>
<li>Accept: 클라이언트가 선호하는 미디어타입</li>
</ul></li>
</ul>
2. HTTP 전송방식
<ul>
<li>단순 전송<ul>
<li>Content-Length를 알면 주면 됨</li>
</ul></li>
<li>압축 전송<ul>
<li>서버에서 압축함</li>
</ul></li>
<li>분할 전송<ul>
<li>Content-Length 보내면 안됨</li>
</ul></li>
<li>범위 전송</li>
</ul>
3. HTTP 정보
<ul>
<li>From : 유저 에이전트 이메일 정보, 검색 엔진에서 사용</li>
<li>Referer : 이전 웹페이지 주소</li>
<li>Host : 요청한 호스트 정보</li>
<li>Location: 리다이렉트하는 주소</li>
</ul>
4. HTTP 인증
<ul>
<li>Authorization: Basic XXXX... </li>
</ul>
5. HTTP 쿠키
<ul>
<li>Set-Cookie: 서버에서 클라로 쿠키 전달</li>
<li>Cookie: 클라가 서버에서 받은 쿠키 저장</li>
<li>쿠키 <ul>
<li>클라가 로그인하면 서버에서 Set-Cookie사용하여 쿠키 정보 담음</li>
<li>웹 브라우저의 쿠키 저장소에 정보 저장</li>
</ul></li>
<li>쿠키 생명주기<ul>
<li>expries: 만료일 되면 쿠키 삭제</li>
<li>max-age: 0이나 음수면 쿠키 삭제</li>
<li>세션쿠키와 영속쿠키가 있음</li>
</ul></li>
<li>쿠키의 도메인<ul>
<li>지정한 도메인에서만!</li>
</ul></li>
<li>쿠키 보안<ul>
<li>Secure<ul>
<li>쿠키는 http, https 구분하지 않고 전송</li>
<li>Secure 적용되어 있으면 https만 전송</li>
</ul></li>
<li>HttpOnly<ul>
<li>XSS 공격 방지</li>
<li>JS에서 접근 불가</li>
<li>HTTP 전송만 사용</li>
</ul></li>
<li>SameSite<ul>
<li>XSRF 공격 방지</li>
<li>요청 도메인, 쿠키 설정된 도메인이 같은 경우만</li>
</ul></li>
</ul></li>
</ul>
<h3 id="캐시">캐시</h3>
1. HTTP 캐시
<ul>
<li>cache-control: 캐시가 유효한 시간</li>
<li>유효 시간이 지나면 브라우저는 데이터를 다시 받음. 근데 데이터가 동일해도 또 받아야 할까?</li>
</ul>
2. 검증 헤더와 조건부 요청
<ul>
<li>last-modified : utc 표기형으로</li>
<li>만약 max-age가 지났으면 검증 헤더에 If-Modified-Since 요청 헤더를 붙여서 서버에 보냄</li>
<li>서버에서 데이터가 수정되었나 검증함</li>
<li>최종수정일을 보고 304 not modified 응답(바디가 없음)</li>
<li>웹 브라우저에서 304를 받으면 헤더 데이터 갱신</li>
</ul>
3. ETag
<ul>
<li>조건부 요청 헤더<ul>
<li>검증 헤더로 조건에 따른 분기</li>
<li>If-Modified-Since: Last-Modified 사용</li>
<li>If-None-Match : ETag 사용</li>
<li>조건 만족하면 200, 조건 만족하지 않으면 304</li>
</ul></li>
<li>ETag<ul>
<li>Entity Tag, 캐시용 데이터 임의의 고유한 버전 이름을 달아둠</li>
<li>데이터 변경되면 이름 바뀌어서 변경함</li>
<li>캐시 제어 로직을 서버에서 완전히 관리</li>
</ul></li>
</ul>
4. 캐시와 조건부 요청 헤더
<ul>
<li>Cache-Control<ul>
<li>no-cache: 데이터는 캐시 되지만, 항상 서버에서 검증</li>
<li>no-store: 데이터에 민감한 정보가 있으므로 저장 안함</li>
</ul></li>
<li>Pragma<ul>
<li>HTTP 1.0 하위 호환</li>
</ul></li>
<li>Expires<ul>
<li>캐시 만료일을 정확한 만료일로 지정, max-ages를 더 권장함</li>
</ul></li>
</ul>
5. 프록시 서버
<ul>
<li>프록시 캐시 <ul>
<li>원 서버를 중개해주는 cdn 서비스처럼 (클라우드프론트) 캐시 서버</li>
</ul></li>
<li>Cache-Control<ul>
<li>public : 응답에 public 캐시, 프록시 캐시</li>
<li>private : 응답이 해당 사용만을 위한 것</li>
<li>s-maxage : 프록시 캐시에 적용되는 max-age</li>
</ul></li>
</ul>
** 인프런 강의 '모든 개발자를 위한 HTTP 웹 기본 지식' 학습 중 
</div></div>

삶도 재입학이 되나요?

HTTP 메서드
API URL
1. 설계
가장 중요한 것은 리소스 식별
리소스의 의미
'회원'이라는 개념 자체가 리소스
회원이라는 리소스만 식별하면 된다.
회원 리소스를 URI에 맵핑
리소스와 행위를 분리
리소스는 명사, 행위는 동사
메서드로 구분한다
2. GET, POST
GET
리소스 조회, 서버에 전달하고 싶은 데이터를 쿼리를 통해 전달
바디를 사용할 수 있지만 권장하지 않음
POST
요청 데이터 처리
메시지 바디를 통해 서버로 요청 데이터 전달
POST는 요청 데이터를 어떻게 처리할까? 
데이터 블록 처리 프로세스 제공
게시판 글쓰기 등
서버가 아직 식별하지 않은 새 리소스 생성
핵심은 POST 요청이 오면 요청마다 어떻게 처리할지 정하는 것!
단순히 데이터 생성, 변경이 아니라 프로세스를 처리하는 것이다
3. PUT, PATCH, DELETE
PUT
리소스를 대체
리소스가 없으면 완전히 대체, 있으면 생성
클라이언트가 리소스를 식별(클라가 리소스 위치를 알고 있음)
요청, 응답의 스펙이 다를 경우 리소스를 덮어버림 (PUT은 리소스 수정이 아님)
PATCH
리소스 부분 변경
4. HTTP 메서드 속성
안전
멱등
한 번이든 백 번이든 결과가 똑같다.
POST는 멱등이 아님
재요청 중 다른 곳에서 리소스 바뀐 건 고려하지 않음
캐시가능
응답 결과를 캐시 사용가능 -> GET만
5. HTTP 메서드 활용
정적 데이터 조회
동적 데이터 조회 
쿼리 파라미터로 조회
HTML Form 전송
웹 브라우저가 Form을 읽어서 HTTP 메시지를 생성해줌.
멀티파트 전송
파일 업로드는 바이너리 데이터 
HTTP API 전송
서버 to 서버
웹 클라이언트에서 ajax로 통신
5. HTTP API 설계 예시
 
6. HTTP 상태 코드
2XX 
201 : created, 요청 성공 후 새로운 리소스 성공
202 : 요청 접수 되어있지만 수행 안됨 
204 : 요청 성공. 근데 응답값은 없음
3xx
리다이렉션: 웹 브라우저는 3xx 응답 결과에 Location 헤더가 있으면 Location 위치로 자동 이동
일시적 리다이렉션 : POST로 주문 후 웹 브라우저 새로고침, 새로고침은 다시 요청 -> 중복요청임
4xx
401: 인증이 되지 않음. 인증(로그인), 인가(권한부여)
헤더
1. HTTP 헤더
표현
Content-Type: 미디어 타입, 문자 인코딩 등
Content-Encoding: 표현데이터 압축, 데이터 읽는 쪽에서 해제 
Content-Language: 표현데이터의 자연 언어 표현
협상
Accept: 클라이언트가 선호하는 미디어타입
2. HTTP 전송방식
단순 전송
Content-Length를 알면 주면 됨
압축 전송
서버에서 압축함
분할 전송
Content-Length 보내면 안됨
범위 전송
3. HTTP 정보
From : 유저 에이전트 이메일 정보, 검색 엔진에서 사용
Referer : 이전 웹페이지 주소
Host : 요청한 호스트 정보
Location: 리다이렉트하는 주소
4. HTTP 인증
Authorization: Basic XXXX... 
5. HTTP 쿠키
Set-Cookie: 서버에서 클라로 쿠키 전달
Cookie: 클라가 서버에서 받은 쿠키 저장
쿠키 
클라가 로그인하면 서버에서 Set-Cookie사용하여 쿠키 정보 담음
웹 브라우저의 쿠키 저장소에 정보 저장
쿠키 생명주기
expries: 만료일 되면 쿠키 삭제
max-age: 0이나 음수면 쿠키 삭제
세션쿠키와 영속쿠키가 있음
쿠키의 도메인
지정한 도메인에서만!
쿠키 보안
Secure
쿠키는 http, https 구분하지 않고 전송
Secure 적용되어 있으면 https만 전송
HttpOnly
XSS 공격 방지
JS에서 접근 불가
HTTP 전송만 사용
SameSite
XSRF 공격 방지
요청 도메인, 쿠키 설정된 도메인이 같은 경우만
캐시
1. HTTP 캐시
cache-control: 캐시가 유효한 시간
유효 시간이 지나면 브라우저는 데이터를 다시 받음. 근데 데이터가 동일해도 또 받아야 할까?
2. 검증 헤더와 조건부 요청
last-modified : utc 표기형으로
만약 max-age가 지났으면 검증 헤더에 If-Modified-Since 요청 헤더를 붙여서 서버에 보냄
서버에서 데이터가 수정되었나 검증함
최종수정일을 보고 304 not modified 응답(바디가 없음)
웹 브라우저에서 304를 받으면 헤더 데이터 갱신
3. ETag
조건부 요청 헤더
검증 헤더로 조건에 따른 분기
If-Modified-Since: Last-Modified 사용
If-None-Match : ETag 사용
조건 만족하면 200, 조건 만족하지 않으면 304
ETag
Entity Tag, 캐시용 데이터 임의의 고유한 버전 이름을 달아둠
데이터 변경되면 이름 바뀌어서 변경함
캐시 제어 로직을 서버에서 완전히 관리
4. 캐시와 조건부 요청 헤더
Cache-Control
no-cache: 데이터는 캐시 되지만, 항상 서버에서 검증
no-store: 데이터에 민감한 정보가 있으므로 저장 안함
Pragma
HTTP 1.0 하위 호환
Expires
캐시 만료일을 정확한 만료일로 지정, max-ages를 더 권장함
5. 프록시 서버
프록시 캐시 
원 서버를 중개해주는 cdn 서비스처럼 (클라우드프론트) 캐시 서버
Cache-Control
public : 응답에 public 캐시, 프록시 캐시
private : 응답이 해당 사용만을 위한 것
s-maxage : 프록시 캐시에 적용되는 max-age
** 인프런 강의 '모든 개발자를 위한 HTTP 웹 기본 지식' 학습 중

HTTP (2)

댓글