HTTP

지정한 IP 주소(IP Address)에 데이터 전달, 목적지 서버를 찾는것IP 패킷 정보 : 출발지 IP, 도착지 IP, 기타 등등을 담고있어야된다.출발지 IP와 도착지 IP의 중간에서 노드를 거쳐 전달된다.패킷(Packet)이라는 통신 단위로 데이터 전달IP 프로토

URI (리소스를 식별한다) URI는 로케이터(locator), 이름(name) 또는 둘 다 추가로 분류될 수 있다. URI = URL(리소스 Locator) + URN(리소스 Name)

HTTP 메시지에 모든 것을 전송HTML, TEXTIMAGE, 음성, JSON, XML거의 모든 형태의 데이터 전송 가능서버간에 데이터를 주고 받을 때도 대부분 HTTP 사용HTTP/1.1 : 가장많이 사용, 우리에게 가장 중요한 버전HTTP/2, HTTP/3 : HT

리소스 란 ?회원을 등록하고 수정하고 조회하는게 리소스가 아니다.예) 미네랄을 캐라 -> 미네랄이 리소스회원이라는 개념 자체가 바로 리소스다리소스를 어떻게 식별하는게 좋을까 ?회원을 등록하고 수정하고 조회하는 것을 모두 배제회원이라는 리소스만 식별하면 된다. -> 회원

리소스를 대체리소스가 있으면 대체리소스가 없으면 생성쉽게 이야기해서 기존에 있는거를 덮어버림예) username : shin , age : 20 에서age : 22를 보내면, username 필드 삭제, age :22로 완전히 대체한다.중요! 클라이언트가 리소스를 식별

쿼리 파라미터를 통한 데이터 전송GET주로 정렬 필터 (검색어)메시지 바디를 통한 데이터 전송POST, PUT, PATCH회원 가입, 상품 주문, 리소스 등록, 리소스 변경정적 데이터 조회이미지, 정적 텍스트 문서동적 데이터 조회주로 검색, 게시판 목록에서 정렬 필터(

HTTP API 설계 예시 HTTP API - 컬렉션 Post 기반 등록 예) 회원 관리, API 제공 > 정리 : "파일" 이 리소스 파일 목록 -> GET 파일 조회 -> GET 파일 등록 -> PUT (신규 자원 등록) 클라이언트가 직접 리소스의 UR

: 요청이 수신되어 처리중 (거의 사용 X): 요청 정상 처리200 : OK201 : Created202 : Accepted204 : No Content: 요청을 완료하려면 클라이언트 프로그램의 추가 행동이 필요리다이렉션 이해웹 브라우저는 3XX 응답의 결과에 Loca

HTTP 전송에 필요한 모든 부가정보예 ) 메시지 바디의 내용, 메시지 바디의 크기, 압축, 인증, 요청 클라이언트, 서버 정보, 캐시 관리 정보표준 헤더가 너무 많음필요시 임의의 헤더 추가 가능helloworld : hihi박스친 부분이 HTTP 헤더이다헤더 분류Ge

회원이라는 리소스를 html이라는 "표현"으로 전달할거야, json "표현"으로 전달할거야Content - Type : 표현 데이터의 형식Content - Encoding : 표현 데이터의 압축 방식Content - Language : 표현 데이터의 자연 언어Conte

Accept : 클라이언트가 선호하는 미디어 타입 전달Accept - Charset : 클라이언트가 선호하는 문자 인코딩Accept - Encoding : 클라이언트가 선호하는 압축 인코딩Accept - Language : 클라이언트가 선호하는 자연 언어협상 헤더는 "

HTTP 전송 방식 단순 전송 Content - Length의 길이를 알경우 사용 예 ) Content - Length :3423 압축 전송 Content - Encoding : "gzip" 어떤 걸로 압축했는지 명시해서 전송 분할 전송 바이트 단위로 쪼개서 보낸다

서버에서 클라이언트로 쿠키 전달 (응답)클라이언트가 서버에서 받은 쿠키를 저장하고, HTTP 요청시 서버로 전달회원 로그인 이후, welcome 페이지 접근 -> 서버에서 로그인한 사용자인지 아닌지 알수없음회원이 보낸 요청인지 아닌지 알수가없음해결 : 모든 요청에 사용

첫 번째 요청1.1M 전송두 번째 요청1.1M 반복해서 똑같이 전송정리 데이터가 변경되지 않아도 계속 네트워크를 통해서 데이터를 다운로드 받아야한다인터넷 네트워크는 매우 느리고 비싸다브라우저 로딩 속도가 느리다.느린 사용자 경험캐시가 유요한 시간(초)응답 결과를 "캐시

서버에서 기존 데이터를 변경함서버에서 기존 데이터를 변경하지 않음캐시 만료 후에도 서버에서 데이터를 변경하지 않음클라이언트의 데이터와 서버의 데이터가 같다는 사실을 확인할수 있는 방법이 필요검증 헤더를 추가하여 데이터가 마지막에 수정된 시간을 표기한다.서버에서 데이터의

캐시 데이터와 서버 데이터가 같은지 검증하는 데이터Last - Modified , ETag검증 헤더로 조건에 따른 분기if - Modified - Since : Last - Modified 사용if - None - Match : ETag 사용조건이 만족하면 200 OK

캐시 제어 헤더 Cache - Control : 캐시 제어 > Cache - Control : max - age 캐시 유효시간, 초 단위 Cache - Control : no - Cache 데이터는 캐시해도 되지만, 항상 원 (Origin) 서버에 검증하고 사용

프록시 캐시 도입웹브라우저가 프록시 캐시 서버를 거쳐서 원 서버에 접근하게 한다.캐시 지시어 (중요 X)Cache - Control : Public응답이 public 캐시에 저장되어도 됨Cache - Control : Private응답이 해당 사용자만을 위한것임, pr