namae

HTTP 헤더 - HTTP 전송에 필요한 모든 부가정보 - 메시지 바디의 내용, 메시지 바디의 크기, 압축, 인증, 요청 클라이언트, 서버 정보, 캐시 관리 정보 - 표준 헤더가 너무 많음 - 필요시 임의의 헤더 추가 가능 HTTP BODY (RFC7230) - 메시지 본문을 통해 표현 데이터 전달 - 메시지 본문 = 페이로드 (payload) - 표현은 요청이나 응답에서 전달할 실제 데이터 - 표현 헤더는 표현 데이터를 해석할 수 있는 정보 제공   - 데이터 유형(html, json), 데이터 길이, 압축 정보 등 - 참고 : 표현 헤더는 표현 메타데이터와, 페이로드 메시지를 구분해야 하지만 여기선 생략 표현 - Content-Type : 표현 데이터의 형식   - 미디어 타입, 문자 인코딩   - ..

1xx : 요청이 수신되어 처리중 - 거의 사용 X 2xx (Successful) : 클라이언트의 요청을 성공적으로 처리 - 200 OK : 요청 성공 - 201 Created : 요청 성공해서 새로운 리소스가 생성됨 - 202 Accepted : 요청이 접수되었으나 처리가 완료되지 않았음 - 204 No Content : 서버가 요청을 성공적으로 수행했지만, 응답 페이로드 본문에 보낼 데이터가 없음   - ex) 웹 문서 편집기의 save 버튼 3xx (Redirection) : 요청을 완료하기 위해 유저 에이전트의 추가 조치 필요 - 웹 브라우저는 3xx 응답의 결과에 Location 헤더가 있으면, Location 위치로 자동 이동 - 영구 리다이렉션 : 특정 리소스의 URI가 영구적으로 이동   ..

HTTP 메서드 활용클라이언트에서 서버로 데이터 전송 - 쿼리 파라미터를 통한 데이터 전송 (폼을 이용하여 전송해도 가능)   - GET   - 주로 정렬 필터(검색어) - 메시지 바디를 통한 데이터 전송   - POST, PUT, PATCH   - 회원 가입, 상품 주문, 리소스 등록, 리소스 변경 4가지 상황 - 정적 데이터 조회   - 이미지, 정적 텍스트 문서   - 조회는 GET 사용   - 정적 데이터는 일반적으로 쿼리 파라미터 없이 리소스 경로로 단순하게 조회 가능  - 동적 데이터 조회   - 주로 검색, 게시판 목록에서 정렬 필터 (검색어)   - 조회 조건을 줄여주는 필터, 조회 결과를 정렬하는 정렬 조건에 주로 사용   - 조회는 GET 사용   - GET은 쿼리 파라미터 사용해서 데..

API URI 설계 - 회원 조회 /read-member-by-id - 회원 등록 /create-member - 회원 수정 /update-member - 회원 삭제 /delete-member 위의 설계는 좋은 URI 설계가 아니다. URI 설계에서 중요한 것은 리소스 식별이다. 리소스란? - 회원의 등록, 수정, 조회하는 것이 아닌 회원이라는 개념 자체가 리소스다. - 회원 등록, 수정, 조회는 모두 배제하고 회원이라는 리소스만 식별하여 URI에 매핑하면 된다. API URI 설계 (리소스 식별, URI 계층 구조 활용) - 회원 목록 조회 /members - 회원 조회 /members/{id} - 회원 등록 /members/{id} - 회원 수정 /members/{id} - 회원 삭제 /members/..

HTTP(HyperText Transfer Protocol) - 서버 간에 통신할 때도 http를 사용한다. - 거의 모든 형태의 데이터를 전송 가능하다.   - HTML, TEXT, JSON, XML, IMAGE, 음성, 영상, 파일 등 기반 프로토콜 - TCP : HTTP/1.1, HTTP/2 - UDP : HTTP/3 - 현재는 HTTP/1.1을 주로 사용한다. HTTP의 특징 - 클라이언트 서버 구조   - Request Response 구조   - 클라이언트는 서버에 요청을 보내고, 응답을 대기   - 서버가 요청에 대한 결과를 만들어서 응답   - 비즈니스 로직, 데이터는 다 서버에 넣는다.   - 클라이언트는 UI, UX를 그리는데 집중한다.  - 무상태 프로토콜(Stateless)   - ..

https://www.google.com/search?q=hello&hl=ko 라는 링크가 있다고 하자.여기서 웹 브라우저는 어떻게 요청하고 응답을 받을까? 먼저 www.google.com:443  (여기서 포트번호 443은 생략가능) 를 이용해 DNS 조회한다.조회에서 얻은 IP에 만든 HTTP 요청 메시지를 보낼 것이다. 이렇게 만든 HTTP 요청 메시지를 SOCKET 라이브러리를 통해 TCP/IP 계층으로 전달한다.여기서 SYN,ACK을 통해 연결, 순서를 보장해 준다.이렇게 연결이 되고 데이터를 받았다면 받은 요청 메시지를 TCP/IP 패킷에 포함시켜 패킷 안에 들어있는 IP, PORT번호에 맞는 서버로 보낸다. 서버에 요청 메시지가 도착하면 서버는 응답 번호, 컨텐트 타입 등을 포함한 응답 메시..

URI는 URL과 URN으로 나눌 수 있다. URI : Uniform Resource Identifier  - 다른 항목과 구분하는데 필요한 정보를 자원을 통해 리소스를 식별하는 통일된 방식  URL : Uniform Resource Locator  - 리소스가 있는 위치를 지정한다.  URN : Uniform Resource Name  - 리소스에 이름을 부여한다.  - 위치는 변할 수 있지만, 이름은 변하지 않는다.  - URN 이름만으로 실제 리소스를 찾을 수 있는 방법이 보편화 되지 않았다. 따라서 URI를 URL과 같은 의미로 작성 하겠다. URL - 구조 : scheme://[userinfo@]host[:port][/path][?query][#fragment]  - scheme : ex) ht..

인터넷에서 통신의 아래의 그림과 같은 방식으로 진행된다.클라이언트에서 서버에 데이터를 보내며 그 사이의 노드들을 거쳐가며 전송이 된다.이와 같이 보내는 과정에서 여러 가지 문제점이 발생할 수 있다.밑에서부터 문제점과 그에 따른 해결 방법들 및 개념들을 설명하겠다. IP(Internet Protocol) - 모든 클라이언트나 서버는 IP주소를 부여받아야 한다. - 클라이언트와 서버 간 통신에는 IP 주소를 통해 데이터를 전달한다. - 이 과정에서 패킷이라는 통신 단위로 전달된다. IP 패킷 정보 - 출발지 IP와, 목적지 IP 등이 있고 내부에는 전송 데이터가 들어있다. IP 프로토콜의 한계 - 출발지 IP와 목적지 IP와 같은 적은 정보로는 여러 가지 문제점이 발생할 수 있다.  1. 비연결성  - 패킷..