클라이언트가 서버와 통신을 하려면 인터넷 즉, IP(인터넷 프로토콜)이 필요하다.클라이언트 IP: 100.100.100.1 => 서버 IP: 200.200.200.2클라이언트인 내가 서버로 메시지를 보내보자.대상 IP 주소에 데이터 전달패킷(packet)이라는 통신
Uniform Resource IdentifierURI? URL? URN?URL: 리소스 위치URN: 리소스 이름URI: 리소스 식별자Uniform: 리소스 식별하는 통일된 방식Resource: 자원, URI로 식별할 수 있는 모든 것 (제한없음)Identifier:
HTML, TEXTIMAGE, 음성, 영상, 파일JSON, XML (API)거의 모든 형태의 데이터 전송 가능서버간에 데이터를 주고 받을 때도 대부분 HTTP 사용HTTP/0.9 1991년: GET 메서드만 지원, HTTP 헤더 없음HTTP/1.0 1996년: 메서드,
URI 설계에 가장 중요한 것은 리소스이다.회원을 등록, 수정, 조회하는 것이 리소스가 아니다.회원이라는 개념 자체가 리소스이다.회원이라는 리소스만 식별하면 된다 => 회원 리소스를 URI에 매핑계층 구조상 상위를 컬렉션으로 보고 복수단어 사용 권장 (member =>
데이터 전달 방식은 크게 2가지쿼리 파라미터를 통한 데이터 전송 \- GET주로 정렬 필터 (검색어)메시지 바디를 통한 데이터 전송 POST, PUT, PATCH회원 가입, 상품 주무느 리소스 등록, 리소스 변경이미지, 정적 텍스트 문서정적 데이터는 일반적으로 쿼리
클라이언트가 보낸 요청의 처리 상태를 응답에서 알려주는 기능1xx (informational): 요청이 수신되어 처리중2xx (Successful): 요청 정상 처리3xx (Redirection): 요청을 완료하려면 추가 행동 필요4xx (Client Error): 클
HTTP 전송에 필요한 모든 부가정보ex) 메시지 바디의 내용, 메시지 바디의 크기, 압축, 인증, 요청 클라이언트, 서버 정보, 캐피 관리 정보 ...표준 헤더가 너무 많음필요시 임의의 헤더 추가 가능General 헤더: 메시지 전체에 적용되는 정보Request 헤더
첫 요청에서 이미지를 다운받고똑같은 요청임에도 다시 다운을 받아야 한다.데이터가 변경되지 않아도 계속 네트워크를 통해서 데이터를 다운로드 받아야 한다.인터넷 네트워크는 매우 느리고 비싸다.브라우저 로딩 속도가 느리다.느린 사용자 경험첫 요청에서 이미지를 다시 요청하자.