📗 CS

message body(페이로드)를 통해 표현 데이터 전달합니다. 표현 데이터는 요청이나 응답에서 전달할 실제 데이터 표현 헤더는 표현 데이터를 해석할 수 있는 정보를 제공 해석 정보 -> 데이터 유형, 데이터 길이, 압축 정보 등 참고 : 표현 헤더는 표현 메타 데이터와, 페이로드 메시지를 구분해야 하지만, 여기서는 생략하겠습니다. 표현 헤더의 표현 > Content Type : 표현 데이터의 형식 > Content-Length : 표현 데이터의 길이 > Content-Encoding : 표현 데이터의 압축 방식 > Content-Language : 표현 데이터의 자연 언어 >> 표현 헤더는 요청(request), 응답(response) 둘다 사용 Content Type (표현 데이터 형식 설명) HT..

상태코드 클라이언트가 보낸 요청의 처리 상태를 응답에서 알려주는 기능 1xx (Informational) : 요청이 수신되어 처리중 2xx (Successful) : 요청 정상 처리 3xx (Redirection) : 요청을 완료하려면 추가 행동 필요 4xx (Client Error) : 클라이언트 오류 -> 잘못된 문법등으로 서버가 요청을 수행할 수 없을 때 5xx (Server Error) : 서버 오류, 서버가 정상 요청을 처리하지 못한 경우 만약 모르는 상태코드가 나타나면 클라이언트는 상위 상태코드로 해석해서 처리합니다. ex ) 299 445 -> 2xx 532 330 -> 5xx 등등.. 제일 앞의 번호로 해석해서 처리합니다. 1xx (Informational) - 요청이 수신되어 처리중일 때..

클라이언트에서 서버로 데이터 전송 시 데이터 전달 방식은 크게 2가지가 있습니다. 1. 쿼리 파라미터를 통한 데이터 전송 GET을 사용한 조회 2. 메시지 바디를 통한 데이터 전송 POST, PUT, PATCH를 이용한 변경 상황으로 보면 크게 4가지가 있죠. 1. 쿼리 파라미터를 통한 데이터 전송에는 두 가지 상황이 있습니다. 1-1. 정적 데이터를 조회 : 이미지, 정적 텍스트 문서 1-2. 동적 데이터를 조회 : 주로 검색, 게시판 목록에서 정렬 필터 2. 메시지 바디를 통해 데이터 전송하는 상황에는 두 가지 상황이 있습니다. 2-1. HTML Form을 통한 데이터 전송 : 회원가입, 상품주문, 데이터 변경 2-2. HTML API를 통한 데이터 전송 : 회원가입, 상품주문, 데이터 변경 ( 서버..

회원 정보 관리 API를 만들려고 할 때, 5가지 요구사항이 주어진다고 해봅시다. 1. 회원 목록 조회 2. 회원 조회 3. 회원 등록 4. 회원 수정 5. 회원 삭제 API URI를 설계할 때는 우선 리소스를 식별하는 것이 중요합니다. 동작은 배제하고 우선 리소스부터 식별하도록 합시다. 여기에서 리소스는 '회원' 이겠죠? 리소스를 식별하고 URI 계층구조를 활용해서 설계를 해보면 이렇게 할 수 있습니다. 1. 회원 목록 조회 /members 2. 회원 조회 /members/{id} 3. 회원 등록 /members/{id} 4. 회원 수정 /members/{id} 5. 회원 삭제 /members/{id} URI는 리소스만 식별하도록 해주고 동작은 분리하도록 합시다. 리소스 : 회원 동작 : 조회, 등록,..

HTTP ( HyperText Transfer Protocol) HTTP 메시지에 모든 것을 담아 전송할 수 있다. ex) HTML, TEXT, 이미지, 음성, 영상, 파일, json, xml 등등... 거의 모든 형태의 데이터를 전송할 수 있음 서버간 데이터를 주고받을 때에도 대부분 HTTP를 사용한다. HTTP 1.1, HTTP 2에서는 TCP 기반 ( 현재는 주로 1.1을 사용한다 ) HTTP 3에서는 UDP 기반 HTTP 특징 클라이언트-서버 구조 Stateless 프로토콜, 비연결성 단순함, 확장가능 클라이언트-서버 구조란? 요청-응답 구조(Request - Response 구조). 클라이언트는 서버로 요청을 보내고, 응답을 대기. 서버는 요청에 대한 결과를 만들어서 응답하는 구조. Statel..