HTTP 상태코드: 클라이언트가 보낸 요청의 처리 상태를 응답에서 알려주는 기능1xx (informational): 요청이 수신되어 처리중2xx (Successful): 요청 정상 처리3xx (Redirection): 요청을 완료하려면 추가 행동이 필요4xx (Client Error): 클라이언트 오류, 잘못된 문법 등으로 서버가 요청을 수행할 수 없음5xx (Server Error): 서버 오류, 서버가 정상 요청을 처리하지 못함만약 모르는 상태 코드가 나타나면?클라이언트가 인식할 수 없는 상태코드를 서버가 반환하면?클라이언트는 상위 상태코드로 해석해서 처리미래에 새로운 상태코드가 추가되어도 클라이언트를 변경하지 않아도 됨ex) 299 ??? -> 2xx (Successful)ex) 451 ??? ->..

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

1️⃣ HTTP API를 만들어보자요구사항: 회원정보 관리 API를 만들어라- 회원 목록 조회, 회원 조회, 회원 등록, 회원 수정, 회원 삭제가장 중요한건 리소스 식별 API URI 고민리소스의 의미는 뭘까?회원을 등록하고 수정하고 조회하는게 리소스가 아니다!ex) 미네랄을 캐라 -> 미네랄이 리소스회원이라는 개념 자체가 바로 리소스다.리소스를 어떻게 식별하는게 좋을까?회원을 등록하고 수정하고 조회하는 것을 모두 배제회원이라는 리소스만 식별하면 된다 -> 회원 리소스를 URI에 매핑회원 목록 조회, 회원 조회, 회원 등록, 회원 수정, 회원 삭제 API URI 설계 - 리소스 식별, URI 계층 구조 활용회원 목록 조회/members회원 조회/members/{id}회원 등록/members/{id}회원 ..

비연결성연결을 유지하지 않는 모델은 서버와 클라이언트간 연결하고,요청과 응답이 오면 연결을 바로 끊음으로서 최소한의 자원이 유지된다.HTTP는 기본적으로 연결을 유지하지 않는 모델일반적으로 초 단위 이하의 빠른 속도로 응답1시간 동안 수천명이 서비스를 이용해도 실제 서버에서 동시에 처리하는 요청은 수십 개 이하로 매우 작음ex) 웹 브라우저에서 계속 연속해서 검색 버튼을 누르지는 않는다서버 자원을 매우 효율적으로 사용할 수 있음HTML문서를 주고 받는 상황에서는 비연결성을 유지하는게 서버 자원을 효율적으로 사용할 수 있다.한계와 극복(단점)TCP/IP 연결을 새로 맺어야 함 - 3 way handshake 시간 추가ex) 내가 페이지를 보다가 다른 페이지로 이동하게 되면 사용자 입장에서는 TCP/IP 연..

모든것이 HTTPHTTP(HyperText Transfer Protocol) - HTTP 메시지에 모든 것을 전송HTML, TEXTIMAGE, 음성, 영상, 파일JSON, XML (API)거의 모든 형태의 데이터 전송 가능서버간에 데이터를 주고 받을 때도 대부분 HTTP 사용지금은 HTTP 시대라고 해도 과언이 아님HTTP 역사HTTP/0.9 (1991): GET 메서드만 지원, HTTP 헤더 XHTTP/1.0 (1996): 메서드, 헤더 추가HTTP/1.1 (1997): 가장 많이 사용, 우리에게 가장 중요한 버전* RFC2068(1997) -> RFC2616(1999) -> RFC7230(2014)HTTP/2 (2015): 성능 개선HTTP/3 진행중: TCP 대신에 UDP 사용, 성능 개선기반 프로..

URI (Uniform Resource Identifier)Uniform: 리소스 식별하는 통일된 방식Resource: 자원, URI로 식별할 수 있는 모든 것(제한 없음)Identifier: 다른 항목과 구분하는데 필요한 정보URL (Uniform Resource Locator), URN (Uniform Resource Name)URL - Locator: 리소스가 있는 위치를 지정URN - Name: 리소스에 이름을 부여위치는 변할 수 있지만, 이름은 변하지 않는다.urn: isbn:8960777331 (어떤 책의 isbn URN)URN 이름만으로 실제 리소스를 찾을 수 있는 방법이 보편화되지 않음URL 전체 문법https://www.google.com:443/search?q=hello&hl=kosch..

PORT PORT는 같은 IP 내에서 프로세스를 구분하기 위한 것 만약 게임을 하고 싶으면 IP 200.200.200.2 의 11220 포트로 전송하면 되는 것. 0 ~ 65535 : 할당 가능0 ~ 1023 : 잘 알려진 포트, 사용하지 않는 것이 좋음FTP - 20, 21TELNET - 23HTTP - 80HTTPS - 443DNS - 도메인 네임 시스템(Domain Name System) 중간에 전화번호부같이 찾아주는 시스템이라고 생각하면 쉬움IP는 기억하기 어렵고, 바뀔 우려가 있음DNS는 도메인 명을 IP 주소로 변환시켜주는 시스템

IP 프로토콜의 한계 비연결성패킷을 받을 대상이 없거나 서비스 불능 상태여도 패킷 전송비신뢰성중간에 패킷이 사라졌을 경우 / 패킷이 순서대로 오지 않을 경우프로그램 구분같은 IP를 사용하는 서버에서 통신하는 애플리케이션이 둘 이상일 경우 클라이언트 측에서는 대상 서버가 패킷을 받을 수 있는 상태인지/아닌지 모른다.-> 모르는 상태에서 패킷을 아무리 전송을 해도, 대상이 서비스 불능인 상태라면 서버측에서 받을 수 없다.패킷이 소실되어도 모른다. 또한, 클라이언트에서 보낸 데이터는 여러 데이터로 쪼개져서 노드를 타게 되는데 이 때 서버에 도착하는 데이터가 요청 데이터와 순서가 완전 일치하다고 보장 할 수는 없다. (중간에 다른 노드를 타게 될 수 있기 때문) 이를 해결하는 것이 TCP프로토콜 인터넷 프로토..