Hyunebee

캐시 유효 시간이 초과해서 서버에 다시 요청하면 다음 두 가지 상황이 나타난다. 1. 서버에서 기존 데이터를 변경함 - 캐시를 갱신하고 다시 네트워크에서 받아야함 2. 서버에서 기존 데이터를 변경하지 않음 변하지 않았다면 데이터를 전송하는 대신에 저장해뒀던 로컬 캐시를 다시 사용할 수있다. but 서버에 있는 데이터가 변하지 않았다는것 을 확인 할 수 있어야 한다. -> 검증헤더 사용 검증 헤더 1 + 조건부 요청 헤더 검증 헤더 2 + 조건부 요청 헤더(ETag) Etag - 캐시용 데이터에 임의의 고유한 버전 이름을 달아둠 -> 데이터가 변경되면 이 이름을 바꾸어 변경함 캐시 제어 로직을 서버에서 완전히 관리 클라이언트는 단순히 이 값을 서버에 제공 - 블랙박스

header-field = field-name : (OWS) field-value (OWS) HTTP 헤더 HTTP 전송에 필요한 모든 부가정보를 담고있음 HTTP 헤더 분류(과거 RFC2616) • General 헤더: 메시지 전체에 적용되는 정보, 예) Connection: close • Request 헤더: 요청 정보, 예) User-Agent: Mozilla/5.0 (Macintosh; ..) • Response 헤더: 응답 정보, 예) Server: Apache • Entity 헤더: 엔티티 바디 정보, 예) Content-Type: text/html, Content-Length: 3423 HTTP BODY(과거 RFC2616) 메시지 본문은 엔티티 본문을 전달하는데 사용한다. 엔티티 헤더는 엔..

HTTP API - 컬렉션 POST기반 등록 회원 관리 시스템 (POST 기반) • 회원 목록 /members -> GET • 회원 등록 /members -> POST 클라이언트는 URI의 리소스의 위치를 모른다. • 회원 조회 /members/{id} -> GET • 회원 수정 /members/{id} -> PATCH, PUT, POST • 회원 삭제 /members/{id} -> DELETE 이러한 형식을 컬렉션이라고 한다. 서버가 관리하는 리소스 디렉토리 서버가 리소스의 URI를 생성하고 관리한다. 여기서 컬렉션은 /members 이다. HTTP API 스토어 PUT 기반 등록 • 파일 목록 /files -> GET • 파일 조회 /files/{filename} -> GET • 파일 등록 /file..

HTTP 설계 • 회원 목록 조회 /read-member-list • 회원 조회 /read-member-by-id • 회원 등록 /create-member • 회원 수정 /update-member • 회원 삭제 /delete-member 이것은 좋은 URI 설계가 아니다 리소스 식별이 가장 중요하다. 회원의 등록 수정 조회 등이 리소스가 아니다. URI는 리소스를 식별하기 위해 사용해야지 행위를 알기위해 사용하면 안됨 회원이 리소스인데 메소드를 어떻게 구분할까? -> HTTP Method들이 대신 처리해준다. • 회원 목록 조회 /members • 회원 조회 /members/{id} • 회원 등록 /members/{id} • 회원 수정 /members/{id} • 회원 삭제 /members/{id} HT..

HTTP? HyperText Trabsfer Protocol 거의 모든 형태의 데이터를 전송 가능 TCP : HTTP/1.1(주로 사용) , HTTP/2 UDP: HTTP/3 HTTP의 특징 1. Client - Server 구조 2. 무상태 프로토콜, 비연결성 3. HTTP메세지 4. 단순함, 확장가능 무상태 프로토콜 서버가 클라이언트의 상태를 보존하지 않음(stateless) -> 무상태는 응답 서버를 쉽게 바꿀 수 있다. (수평 확장 유리) -> 클라이언트의 요청이 증가해도 서버를 대거 투입할 수 있다. 한계점 1.모든 것을 무상태로 설계 할 수 있는 경우도 있고 없는 경우도 있다. 로그인: 상태 유지 로그인한 사용자의 경우 로그인 했다는 상태를 서버에 유지 일반적으로는 쿠키와 서버 세션을 사용해서..

URI(Uniform Resource Identifier ) URI는 Locator , Name 또는 둘다 추가로 분류할 수 있다. Uniform : 리소스를 식별하는 통일 된 방식 Resource : 자원(URI로 식별할 수 있는 모든 것) Identifier : 다른 항목과 구분하는데 필요한 정보 URL(Uniform Resource Locator) URN(Uniform Resource Name) URL 분석 https://www.google.com/search?q=hello&hi=ko scheme://[userinfo@]host[:port][/path][?query][#fragment] scheme : 어떤 방식으로 자원에 접근할 것인가 하는 약속 규칙(http, https, ftp ) userin..

Client -> internet -> server 어떻게 복잡한 인터넷을 통해 서버로 전달하는가?? -> ip 사용 IP(Internet Protocol) Source ip -> Destination ip를 통해서 전송 IP 프로토콜의 한계 비연결성 패킷을 받을 대상이 없거나 서비스 불능 상태여도 패킷 전송 전송할 대상이 패킷을 받을 수 있는 상태인지 모름 비신뢰성 중간에 패킷이 사라진다면? 패킷이 순서대로 안오면? 모든 패킷이 같은 노드를 타지 않을 수 있음 프로그램 구분 같은 IP를 사용하는 서버에서 통신하는 애플리케이션이 둘 이상이라면?? TCP 프로토콜 IP만으로 해결이 안되던 오류제어 흐름제어 혼잡제어등을 해결할 수 있게 됨 TCP의 특징 1.연결지향(3way handshake-(가상 연결))..