[8주차] 김민진 학습 PR 제출합니다.

week08/김민진.md

@@ -0,0 +1,180 @@
+# JAVA HTTP
+
+### 인터넷과 네트워크
+
+- 인터넷
+    - 전 세계적으로 연결된 컴퓨터 네트워크의 집합체로서 정보와 데이터를 주고받을 수 있는 거대한 광역 네트워크
+    - 수많은 개별적인 네트워크들이 상호 연결되어 하나의 거대한 정보 공유 시스템을 형성
+    - 인터넷을 통해 이메일, 웹사이트, 파일 공유, 온라인 스트리밍, 온라인 게임 등 다양한 서비스 이용 가능
+    - 미국의 군사 연구 기관인 ARPA에서 1960년대 말에 개발된 ARPANET에서 시작
+    - 전 세계적으로 다양한 네트워크들이 연결되면서 인터넷 형성
+    - IP와 RCP를 기반으로 동작
+    - 탄력성
+        - 장애가 발생해도 데이터는 대체 경로를 통해 전송되어 목적지에 도달
+    - 개방성
+        - 누구나 인터넷에 연결되어 정보를 검색하고 공유 가능
+    - 분산성
+        - 중앙 집중형이 아닌 여러 노드로 구성되어 있어 안정성이 높음
+- 네트워크
+    - 서로 연결된 컴퓨터와 기타 장치들 간에 데이터를 교환할 수 있도록 해주는 구조
+    - 네트워크를 통해 컴퓨터, 스마트폰, 프린터, 서버 등 다양한 장치들이 서로 통신하고 자원 공유 가능
+    - 랜(Local Area Network)
+        - 한정된 지역에서 사용되는 네트워크
+        - 주로 이더넷(Ethernet) 케이블이나 Wi-Fi를 사용하여 구성
+    - 왠(Wide Area Network)
+        - 넓은 지역에 분산된 지역들을 연결하는 네트워크
+        - 인터넷이 대표적인 예시
+    - 라우터, 스위치, 허브 등의 장치들로 구성되며 데이터를 전달하고 전송하는 역할 수행
+- 인터넷과 네트워크 동작 원리
+    - 인터넷과 네트워크는 패킷이라고 하는 작은 조각으로 분할하여 전송
+    - 데이터를 패킷으로 나누면 경로 상의 다양한 노드들을 효율적으로 통과 가능
+    - 각 패킷은 목적지 주소와 출발지 주소를 포함하여 정보를 보낼 위치를 지시
+    - 데이터 전송 순서
+        - 데이터 분할: 전송할 데이터를 작은 패킷으로 나눔
+        - 패킷 라우팅: 각 패킷은 목적지까지 가장 효율적인 경로를 통해 전달
+        - 패킷 전송: 각 노드가 패킷을 수신하고 다음 노드로 전달
+        - 패킷 재조립: 목적지에서는 패킷들이 순서대로 수신되고 원래의 데이터로 재조립됨
+        - 빠른 속도와 안정성 보장
+
+### http
+
+- 인터넷 상에서 웹 페이지와 같은 리소스를 전송하기 위해 사용되는 프로토콜
+- 클라이언트-서버 모델을 기반으로 하며, 클라이언트가 요청을 보내고, 서버가 해당 요청에 대해 응답을 제공하는 방식으로 동작
+- 웹 브라우저가 가장 흔한 HTTP 클라이언트의 예시
+- 인터넷을 기반으로 하는 매우 중요한 프로토콜로, 웹 브라우저를 통해 웹 페이지를 요청하고 보는 데에 사용되는 핵심 기술
+- 여러 많은 애플리케이션들도 HTTP를 기반으로 하여 데이터를 주고 받을 수 있음
+- HTTP는 간단하고 직관적인 프로토콜이며, 주로 요청과 응답으로 이뤄짐
+- 각각의 요청과 응답은 일련의 텍스트 기반 메시지로 구성
+- 요청 메시지는 클라이언트가 서버로 보내는 요청을 설명하고, 응답 메시지는 서버가 클라이언트에게 제공하는 리소스나 상태를 포함
+- 기본적으로 상태를 유지하지 않는 stateless 프로토콜
+- 이전 요청과 현재 요청이 서로 독립적으로 처리
+- 쿠키와 세션과 같은 메커니즘을 사용하여 상태 관리
+- HTTPS
+    - 보안 기능이 추가된 HTTP의 변형
+    - 데이터를 암호화하여 보호하는 보안 프로토콜
+    - SSL(Secure Sockets Layer) 또는 TLS(Transprot Layer Security) 프로토콜을 사용하여 데이터의 안전한 전송을 보장
+    - HTTPS를 사용하면 데이터가 암호화되어 전송되므로 중간에 누군가가 데이터를 가로채더라도 해독하기 어려움
+    - 민감한 정보를 주고 받거나 로그인 등의 인증이 필요한 경우에는 HTTPS를 사용하는 것이 안전
+
+### http 메서드
+
+- HTTP 프로토콜을 사용하여 서버에 요청을 보낼 때, 수행하고자 하는 동작을 지정하는 방법
+- 요청을 통해 서버에게 어떤 동작을 해야 하는 지를 알려주는 역할
+- GET
+    - 리소스를 가져오기 위해 서버에 요청
+    - 주로 웹페이지, 이미지, 비디오, 텍스트 파일 등을 가져올 때 사용
+    - 서버의 데이터나 상태를 변경하지 않으며 캐싱될 수 있음
+    - 동일한 GET요청을 여러 번 보내도 동일한 응답을 받게 됨
+- POST
+    - 서버에 새로운 데이터를 전송하거나 리소스를 생성하기 위해 사용
+    - 주로 폼 데이터를 서버로 제출하는 용도로 많이 사용됨
+    - 서버의 데이터나 상태를 변경할 수 있으며, 요청 본문에 데이터를 담아 보낼 수 있음
+- PUT
+    - 서버에 새로운 데이터를 전송하거나, 기존 데이터를 수정(업데이트)하기 위해 사용
+    - 주로 리소스의 전체 내용을 교체할 때 사용
+- PATCH
+    - PUT과 비슷하게 서버에 데이터를 수정하기 위해 사용
+    - PUT이 리소스 전체를 교체하는 데 사용되는 반면, PATCH는 부분적인 수정에 사용됨
+    - 리소스의 일부만 수정하고자 할 때 사용
+- DELETE
+    - 서버에서 특정 리소스를 삭제하기 위해 사용됨
+    - 해당 리소스를 삭제하면 서버에서 해당 리소스에 대한 정보를 완전히 제거
+
+### http 상태코드
+
+- 클라이언트가 서버에 보낸 요청에 대한 처리 결과를 나타내는 세 자리 숫자
+- 웹 서버는 클라이언트의 요청을 받아들이고 처리한 후에 상태 코드를 응답으로 반환
+- 클라이언트에게 해당 요청이 성공적으로 처리되었는지, 오류가 발생했는지, 또는 추가 조치가 필요한지 등을 알려줌
+- HTTP 상태 코드를 이해하면 클라이언트와 서버 간의 통신 문제를 더 쉽게 이해하고 디버깅할 수 있음
+- 1XX: 요청성공, 아직 처리중, 정보성 응답
+- 2XX: 요청 처리 성공
+- 3XX: 리다이렉션
+- 4XX: 잘못된 요청
+- 5XX: 서버 오류
+- 200 OK
+    - 클라이언트의 요청이 성공적으로 처리되었음
+    - 요청이 성공했을 때 가장 일반적으로 사용되는 상태 코드
+- 201 Created
+    - POST 요청이 성공하여 새로운 리소스가 성공적으로 생성되었음
+- 204 No Content
+    - 요청은 성공했지만, 서버가 응답 본문에 어떤 데이터도 보내지 않았음
+    - 주로 PUT 또는 DELETE 요청에 사용
+- 301 Moved Permanently
+    - 요청한 리소스가 새로운 URL로 영구적으로 이동되었음
+    - 브라우저는 새로운 URL로 리다이렉트하도록 할 수 있음
+- 400 Bad Request
+    - 클라이언트의 요청이 잘못되어 서버가 요청을 이해하지 못할 경우 사용
+- 401 Unauthorized
+    - 클라이언트가 인증되지 않았거나 인증 정보가 잘못된 경우 사용
+    - 보호된 리소스에 접근하려 할 때 인증이 필요할 때 주로 사용
+- 403 Forbidden
+    - 클라이언트가 인증은 되었지만 해당 리소스에 접근할 권한이 없는 경우 사용
+- 404 Not Found
+    - 요청한 리소스를 찾을 수 없는 경우 사용
+    - 가장 흔한 404 오류는 존재하지 않는 URL에 접근했을 때 발생
+- 500 Internal Server Error
+    - 서버가 요청을 처리하는 동안 내부 오류가 발생한 경우 사용
+- 503 Service Unavailable
+    - 서버가 현재 요청을 처리할 수 없는 상태인 경우 사용
+    - 주로 서버 점검 등의 이유로 사용
+
+### http 헤더
+
+- HTTP 요청과 응답 메시지에 추가 정보를 포함시키는 방법
+- 헤더는 키-값 쌍의 형태로 구성되며, 클라이언트와 서버 간의 통신을 돕고 추가적인 메타데이터를 전달하는 역할을 함
+- 클라이언트와 서버 간의 통신을 개선하고 추가 정보를 전달하는 데에 중요한 역할을 함
+- 헤더는 HTTP 메시지의 일부로 보내지므로, 헤더의 정보는 보통 숨겨져 있지 않으며 누구나 볼 수 있음
+- 요청 헤더 (Request Headers)
+    - Host: 요청한 호스트(웹 서버)의 도메인 이름 또는 IP 주소를 지정
+    - User-Agent: 클라이언트 애플리케이션의 정보를 포함하여 서버에게 어떤 브라우저나 애플리케이션에서 요청이 발생했는지를 알려줌
+    - Accept: 클라이언트가 처리 가능한 콘텐츠 타입(미디어 타입)을 서버에 알려줌
+    - Authorization: 클라이언트의 인증 정보를 서버에 전달, 일반적으로 사용자 이름과 비밀번호를 인코딩하여 Basic 인증에 사용
+    - Content-Type: 요청 본문의 미디어 타입을 지정, POST 메서드와 함께 데이터를 전송할 때 사용
+    - Cookie: 클라이언트의 쿠키 정보를 서버에 전달, 이전 요청에서 서버가 보낸 쿠키를 서버에게 재전송할 때 사용
+- 응답 헤더 (Response Headers)
+    - Content-Type: 서버가 보내는 응답 본문의 미디어 타입을 지정, 클라이언트가 적절한 방식으로 응답을 처리할 수 있도록 함
+    - Content-Length: 응답 본문의 길이를 바이트 단위로 나타냄, 클라이언트는 응답 데이터를 제대로 수신하기 위해 이 값을 사용
+    - Location: 리다이렉션 시 새로운 리소스의 URL을 클라이언트에게 알려줌
+    - Set-Cookie: 서버가 클라이언트에게 쿠키를 설정하거나 업데이트할 때 사용
+    - Cache-Control: 클라이언트에서 리소스를 캐시할 때 캐시 제어에 사용됨
+- 엔티티 헤더 (Entity Headers)
+    - 요청 또는 응답 메시지의 본문을 설명하는 헤더
+    - 주로 POST 요청이나 PUT 요청 등에서 사용
+
+### Rest API
+
+- 웹 서비스의 아키텍처 스타일 중 하나로, 클라이언트와 서버 간의 통신을 위한 규칙과 제약을 정의한 인터페이스
+- 네트워크 아키텍처를 활용하여 분산 시스템을 구축하는 데에 많이 사용되며, 주로 HTTP 프로토콜을 기반으로 동작
+- 현대적인 웹 애플리케이션의 개발과 통합에서 매우 중요한 역할을 하고 있으며, 다양한 플랫폼과 기기에서 활용될 수 있도록 설계되어 있음
+- 자원(Resource)
+    - 모든 자원은 고유한 식별자(URI 또는 URL)로 식별되어야 함
+    - 자원은 서버에 존재하며, 데이터베이스, 파일, 이미지, 텍스트 등 어떤 종류의 데이터든 될 수 있음
+- 표현(Representation)
+    - 클라이언트가 요청한 자원은 적절한 표현(Representation)을 통해 전달
+    - 예를 들어 JSON, XML, HTML 등의 형식으로 데이터가 전송될 수 있음
+- 상태(Stateless)
+    - 서버는 각 요청에 대한 클라이언트의 상태 정보를 저장하지 않음
+    - 클라이언트의 상태는 요청과 함께 전송되어야 함
+    - 서버의 확장성이 증가하고, 클라이언트와 서버 간의 독립성이 보장
+- 통일된 인터페이스(Uniform Interface)
+    - REST API는 통일된 인터페이스를 갖추어야 함.
+    - HTTP 메서드와 URL을 통해 리소스에 접근하고 조작하는 방식을 일관성 있게 정의하는 것을 의미
+- 자체 표현(Self-descriptive)
+    - REST API는 자체 표현 구조로 되어있어, 클라이언트가 API를 사용할 때 추가적인 문서(documentation)의 의존성을 낮춤
+    - 각 리소스의 타입과 어떤 동작을 수행할 수 있는지를 API 자체에서 알 수 있어야
+- REST API 메서드
+    - GET: 리소스를 조회할 때 사용
+    - POST: 새로운 리소스를 생성할 때 사용
+    - PUT: 리소스를 업데이트(수정)할 때 사용
+    - DELETE: 리소스를 삭제할 때 사용
+
+### **Entity간의 연관 관계의 주인**
+
+- 엔티티(Entity)간의 연관 관계에서 주인(Owner)은 양방향 연관 관계에서 데이터베이스에서 외래 키(Foreign Key)를 관리하는 책임을 지는 쪽을 가리킴.
+- 주인이 아닌 쪽은 데이터베이스에서 외래 키를 관리하지 않음.
+- 일반적으로 JPA(Java Persistence API)나 Hibernate와 같은 ORM(Object-Relational Mapping) 프레임워크를 사용할 때, 엔티티 간의 연관 관계를 매핑할 때 주인을 명시해야 함.
+- 연관관계의 주인이라고 비지니스 로직에 더 중요한 것이 아님.
+- 비지니스 중요도를 제거하고 단순히 외래 키 관리자의 의미만 부여
+- 자동자와 바퀴의 관계에서 자동차가 더 중요해보이지만 바퀴가 외래키를 가진 연관관계 주인
+- 일반적으로는 외래 키가 있는 쪽을 주인으로 정하는 것이 권장. 데이터베이스와 객체 간의 일관성을 유지
+- 주인이 아닌 쪽은 읽기 전용(read-only)으로 설정되며, mappedBy 속성을 사용하여 주인을 지정