YJ의 새벽

private 캐시 -> public 캐시 캐시 무효화 -- Chche-Control : no-cache, no-store, must-revalidate -- Pragma : co-cache ( HTTP 1.0 하위호환 대비 ) -- 위에 적은 그대로 다 넣어주자 .!! --Chche-Control : no-cache - 데이터는 캐시해도 되지만, 항상 원서버에 검증하고 사용 (이름주의) --Chche-Control : no-store - 데이터에 민감한 정보가 있으므로 저장하면 안됨 ( 메모리사용후 빨리삭제 ) --Chche-Control : must-revalidate - 캐시 만료후 최초조회시 원 서버에 검증해야함. - 원 서버 접근실패시, 반드시 오류발생 - 504 error - 캐시 유효시간이라..

검증헤더 --캐시 데이터와 서버 데이터가 같은지 검증하는 데이터 -- Last-Modified , ETag 조건부 요청 헤더 -- 검증 헤더로 조건에 따른 분기 -- If-Modified-Since : Last-Modified 사용 -- If-None-Match : ETag 사용 -- 조건이 만족하면 200 error OK -- 조건이 만족하지 않으면 304 Not Modified -- If-Modified-Since 예시 : Last-Modified -- If-Modified-Since 예시 : Last-Modified -- 단점 : 1초 미만( 0.x ) 단위로 캐시 조정이 불가능 : 날짜 기반의 로직 사용 : 데이터를 수정해서 날짜가 다르지만, 같은 데이터를 수정해서 데이터 결과가 똑같은경우 : 서..

캐시 기본 동작 *** 캐시가 없을때 -- 데이터가 변경되지 않아도 계속 네트워크를 통해서 데이터를 다운받아야한다. -- 인터넷 네트워크는 느리고 비싸다. -- 브라우저 로딩 속도가 느리다. *** 캐시적용 -- 캐시 덕분에 캐시 가능시간동안 네트워크를 사용하지 않아도 된다. -- 비싼 네트워크 사용량을 줄일수있다. -- 브라우저 로딩속도가 빠르다. *** 캐시 시간 초과 -- 캐시 유효시간이 초과하면, 서버를 통해 데이터를 다시 조회하고, 캐시를 갱신. -- 네트워크 다운로드가 다시 발생한다. !! 모든 개발자를 위한 HTTP 웹 기본 지식 - 인프런 | 강의 실무에 꼭 필요한 HTTP 핵심 기능과 올바른 HTTP API 설계 방법을 학습합니다., - 강의 소개 | 인프런 www.inflearn.com

HTTP 헤더 용도 -- HTTP 전송에 필요한 모든 부가정보 -- 메시지 바디의 내용 , 바디의 크기, 압축, 인증, 요청클라이언트, 서버정보, 캐시 ....등 -- 표준 헤더가 너무 많다. -- 필요시 임의의 헤더 추가 가능. HTTP 헤더 분류 -- General 헤더 : 메시지 전체에 적용되는 정보. ex ) Connection : close . -- Request 헤더 : 요청 정보, ex ) User-Agent : Mozilla/5.0 . -- Response 헤더 : 응답 정보 ex ) Server.Apache -- Entity 헤더 : 엔티티 바디 정보 ex ) Content-Type : text/html , Content-Length : 3423 표현헤더 -- Content-Type : ..

상태 코드 --클라이언트가 보낸 요청의 처리 상태를 응답에서 알려주는 기능 -- 1xx ( Infromational ) : 요청이 수신되어 처리중 *거의 사용 x -- 2xx ( Successful ) : 요청 정상 처리 -- 3xx ( Redirection ) : 요청을 완료하려면 추가 행동이 필요 -- 4xx ( Client Error ) : 클라이언트 오류, 잘못된 문법등으로 서버가 요청을 수행할수 없음 -- 5xx ( Server Error ) : 서버 오류 , 서버가 정상 요청을 처리하지 못함. 2 xx - Successful 요청정상처리 -- 200 OK -- 201 Created -- 202 Accepted -- 204 No Content 202 Accepted -- 요청이 접수되었으나 처리..

어떤 용도에 메서드들이 쓰이는지 확인해보자 . HTML FORM ?? -- HTML FORM 은 GET , POST 만 지원 . -- .ajax 를 사용해서 해결 가능 . -- 컨트롤 URI -GET,POST 만 지원하므로 제약이 있음. -이런 제약을 해결하기위해 동사로 된 리소스 경로 사용 -POST의 /new , /edit , /delete 가 컨트롤 URI URL 설계개념 ** 문서 ( document ) -- 단일 개념 (파일하나, 객체 인스턴스, 데이터베이스row ) ex ) /members/100 , /files/stat.fpg ** 컬렉션 ( collection ) -- 서버가 관리하는 리소스 디렉터리 -- 서버가 리소스의 URI 를 생성하고 관리 ex ) /members ** 스토어 ( s..

-- 클라이언트에서 서버로 데이터 전송 방법. 1 ) 쿼리 파라미터를 통한 데이터 전송 -- GET -- 주로 정렬 필터 (검색어) 2 ) 메시지 바디를 통한 데이터 전송 -- POST, PUT, PATCH -- 회원가입, 상품주문, 리소스등록, 리소스변경 .. 정적 데이터 조회 -- 이미지 , 정적 텍스트 문서 -- 조회는 GET 사용 , -- 정적 데이터는 일반적으로 쿼리 파라미터 없이 리소스 경로로 단순하게 조회 가능 동적 데이터 조회 -- 주로 검색, 게시판 목록에서 정렬필터 ( 검색어 ) -- 조회 조건을 줄여주는 필터, 조회 결과를 정렬하는 정렬조건에 주로 사용 -- 조회는 GET 사용 -- GET 은 쿼리 파라미터 사용해서 데이터를 전달 HTML Form 을 통한 데이터 전송 -- 회원가입 ..

HTTP 메서드의 속성 -- 안전 ( Safe Methods ) -- 멱등 ( Idempotent Methods ) -- 캐시가능 ( Cacheable Methods ) *** 안전 Safe ( GET , HEAD ) -- 호출해도 리소스를 변경하지 않는다 . *** 멱등 Idempotent -- 한번호출하든, 두번호출하든 , 100번 호출하든 결과가 똑같다 .!!! GET : 한번조회하든, 두번조회하든 같은결과 조회 PUT : 결과를 대체 , 따라서 같은요청을 해도 최종결과는 같다. DELETE : 결과삭제 , 같은요청을해도 삭제된 결과는 같다. POST : 멱등이 아니다 !! 두번호출하면 같은결제가 중복해서 발생할수 있다 .! -- 자동 복구 메커니즘 . -- 서버가 TIMEOUT 등으로 정상응답을 ..