[Yunjanghyeon] 프론트엔드 2주차 미션 제출합니다.

mission1/WIL.md

@@ -0,0 +1,153 @@
+# 프론트엔드와 백엔드의 소통
+
+프론트엔드는 (당연한건 안씀)
+- 라이브러리(react 등)와 프레임워크(Next.js)를 사용
+- 클라이언트 측임 (백엔드는 서버 측)
+- 데이터 보여줌
+
+백엔드는
+- 서버관리
+- 다양한 언어와 프레임워크 사용(python - django, java-spring 등)
+- 서버 측임
+- 데이터 저장함
+이다
+
+프론트와 백엔드는 소통할 때
+- http 프로토콜(통신 규약? 이렇게 통신해요 우리 느낌)
+- API 통신(데이터 주고받는거)
+- 비동기 통신(동기 통신 반댓말, 요청하고 응답 기다리지않고 딴일하는거)
+이런 원리가 있어요
+
+연결 방법엔
+- Restful API(Restful 원칙 따르는거)
+- GraphQL(요즘 뜨고있음, 데이터형식 지정하여 요청 가능)
+- WebSocket(실시간통신 필요할떄 사용, html보다 빠름)
+- Server-Sent Events (SSE)(서버 to 클라이언트 데이터 전송떄 사용)
+이 있어요
+
+# HTTP 요청/응답 공부
+먼저 HTTP 요청/응답엔 공통적인 구조가 있는데
+1. 시작줄
+2. HTTP 헤더
+3. 빈 줄
+4. 본문 요청과 관련된 데이터/ 응답과 관련된 데이터
+가 있습니다
+
+# 시작 줄
+HTTP 메소드 + URI + HTTP 버전으로 이루어져있는데
+
+HTTP 메소드에는 GET/POST/HEAD/OPTIONS 등의 서버가 할 동작을 적습니다.
+메소드를 정리해보자면 (1주차 HTML5 1.9에도 일부 있는 내용)
+
+*참고:멱등성이란 동일한 연산을 여러 번 수행해도 결과가 달라지지 않는 성질*
+## GET
+리소스를 조회(ex: 클라이언트가 서버에게 페이지 보여달라고 요청, 링크 클릭 등)
+**쿼리스트링** 사용
+멱동성을 지님
+
+## POST
+새로운 리소스 생성하는데 사용
+성공적으로 생성하면 201 HTTP 응답 반환(201도 HTTP STATUS?)
+데이터를 **메세지 바디**에 쿼리 파라미터(key-value 형식으로 되어있음)형식으로 전달
+GET 방식과 비교해서 데이터 외부 노출 안되는 이점 있음
+다만 멱동성을 지니지 않고 조회속도가 GET에 비해 느림
+
+## PUT
+리소스를 완전히 대체하는 개념
+클라이언트가 리소스를 식별할 수 있음(PUT/posts/1 : 1번 게시글 수정 요청)
+부분 수정 불가능(기존에 A,B 데이터가 있는데 C라는 데이터를 담아 PUT요청보내면 A,B삭제되고 C로 대체)
+멱동성을 지님
+
+## PATCH
+PUT과 같이 리소스를 변경하는데, 얘는 부분 변경함
+기존 A,B 데이터가 있는데 B=C로 대체후 PATCH 요청 보내면 데이터가 A,C로 변경됨
+PATCH 매서드 지원안하는 서버는 POST 사용
+멱동성 지니지 않음
+
+## DELETE   
+리소스 제거 역할
+멱동성을 지님
+.
+.
+.
+
+URI에는 URL 또는 포트, 도메인 등의 절대경로가 옵니다
+URI 포멧에는
+- origin 형식: 끝에 '?'와 쿼리 문자열이 붙는 절대경로. GET, POST, HEAD, OPTIONS 메소드와 함께 쓰임
+- absolute 형식: 완전한 URL 형식(http://www.naver.com), 대부분 GET 메소드를 씀
+- authority 형식: 도메인 이름 및 옵션 포트(':'가 앞에 붙는 형태)로 이루어진 URL의 authority component. HTTP 터널 구축하는 경우에만 CONNECT와 함꼐 사용(이거 잘 모르겠어요)
+- asterisk 방식: OPTIONS 메소드와 함꼐 * 하나로 간단하게 서버 전체 나타냄.
+이 옵니다
+
+HTTP 버전에는
+응답 메시지에서 써야할 HTTP 버전을 알려줍니다.
+
+# HTTP 헤더
+대소문자를 구분하지 않는 이름, 클론(:), 값으로 구성됩니다
+헤더는 값까지 포함해 한줄로 구성되지만 길 수 있습니다
+그룹을 나눌 수 있는데
+- Request 헤더: 요청 내용 구체화, 컨텍스트 제공
+- General 헤더: 메시지 전체에 적용되는 헤더
+- Entity 헤더: 요청 본문에 적용되는 헤더, 요청 내에 본문이 없는 경우에는 전송되지 않음
+
+# 본문
+요청의 마지막 부분에 들어가며, GET, HEAD, DELETE , OPTIONS처럼 리소스를 가져오는 요청에서는 보통 본문이 필요없다
+본문은 두종류로 나뉨
+- 단일-리소스 본문(single-resource bodies): 헤더 두 개(Content-Type와 Content-Length)로 정의된 단일 파일로 구성된다.
+- 다중-리소스 본문(multiple-resource bodies): multipart 본문으로 구성되며, 파트마다 다른 정보를 포함한다. 보통 HTML Form과 관련이 있음.
+
+# 상태 줄
+프로토콜 버전 + 상태 코드 + 상태 텍스트로 구성되있습니다
+프로토콜 버전: 보통 HTTP/1.1 입니다
+상태 코드: 요청의 성공 또는 실패를 숫자 코드로 나타낸다. 200, 404 혹은 302 등이 있습니다
+상태 텍스트: 짧고 간결하게 상태 코드에 대한 설명을 글로 나타내어 사람들이 HTTP 메시지를 이해할 때 도움이 됩니다
+EX)HTTP/1.1 404 Not Found.
+
+# 헤더
+요청의 헤더 설명과 다르지 않습니다
+
+# 본문
+모든 응답에 본문이 들어가지는 않습니다 (ex: 201, 204같은 상태코드)
+본문은 세종류로 나뉩니다
+- 이미 길이가 알려진 단일 파일로 구성된, 단일-리소스 본문: 헤더 두개(Content-Type와 Content-Length)로 정의한다
+- 길이를 모르는 단일 파일로 구성된, 단일-리소스 본문: Transfer-Encoding가 chunked로 설정되어 있으며, 파일은 청크로 나뉘어 인코딩 되어 있다.
+- 서로 다른 정보를 담고 있는 multipart로 이루어진 다중 리소스 본문: 이 경우는 위의 두 경우에 비해 상대적으로 보기 힘들다.
+
+# HTTP 상태 코드 정리 
+[출처1](https://hongong.hanbit.co.kr/http-%EC%83%81%ED%83%9C-%EC%BD%94%EB%93%9C-%ED%91%9C-1xx-5xx-%EC%A0%84%EC%B2%B4-%EC%9A%94%EC%95%BD-%EC%A0%95%EB%A6%AC/)
+[출처2](https://developer.mozilla.org/ko/docs/Web/HTTP/Status#%EC%84%B1%EA%B3%B5_%EC%9D%91%EB%8B%B5)
+## 정보 응답
+1XX으로 시작, 임시 응답으로 현재 클라이언트의 요청까지는 처리되었으니 계속 진행하라는 의미
+
+- 100 continue(계속): 지금까지의 상태가 괜찮으며 클라이언트가 계속해서 요청을 하거나 이미 요청을 완료한 경우에는 무시해도됨
+- 101 Switching protocol(프로토콜 전환): 클라이언트가 보낸 Upgrade 요청 헤더에 대한 응답에 들어가며 서버에서 프로토콜을 변경할 것임을 알려줌
+- 102 102 Processing(처리중): 서버가 요청을 수신하였으며 이를 처리하고 있지만, 아직 제대로 된 응답을 알려줄 수 없음을 알려줌
+- 103 Early Hints: 주로 Link 헤더와 함께 사용되어 서버가 응답을 준비하는 동안 사용자 에이전트가(user agent) 사전 로딩(preloading)을 시작할 수 있도록 한다.
+
+## 성공 응답
+2XX로 시작, 라이언트의 요청이 서버에서 성공적으로 처리되었다는 의미
+- 200 OK: 요청이 성공적으로 됨/응답 헤더 Location에 새로운 리소스의 절대 URI를 기록
+- 201 Created: 요청이 성공적이었으며 그 결과로 새로운 리소스가 생성됨/ 응답 헤더 Location에 새로운 리소스의 절대 URI를 기록
+- 202 Accepted: 요청은 접수하였지만, 처리가 완료되지 않음/응답 헤더의 Location, Retry-After를 참고하여 클라이언트는 다시 요청을 보냄
+
+## 리다이렉션
+3XX로 시작, 완전한 처리를 위해서 추가 동작이 필요한 경우, 주로 서버의 주소 또는 요청한 URI의 웹 문서가 이동되었으니 그 주소로 다시 시도하라는 의미
+- 300 Multiple Choices: 선택 항목이 여러 개 있음/ 지정한 URI에 대해서 콘텐츠 협상을 수행한 결과 서버에서 콘텐츠를 결정하지 못하고 클라이언트에게 복수 개의 링크를 응답할 때 사용
+- 301 Moved Permanently: 지정한 리소스가 새로운 URI로 이동됨/ 이동할 곳의 새로운 URI는 응답 헤더 Location에 기록
+- 303 See Other: 다른 위치로 요청하라./ 요청에 대한 처리 결과를 응답 헤더 Location에 표시된 URI에서 GET으로 취득할 수 있음
+- 307 Temporary Redirect: 임시로 리다이렉션 요청이 필요하다/ 요청한 URI가 없으므로 클라이언트 메소드를 그대로 유지한 채 응답 헤더 Location에 표시된 다른 URI로 요청을 재송신할 필요가 있음
+
+## 클라이언트 에러
+4XX로 시작, 없는 페이지를 요청하는 등 클라이언트의 요청 메시지 내용이 잘못된 경우를 의미
+- 400 Bad Request: 요청의 구문이 잘못되었다, 4xx 계열 응답 코드가 반환된 경우에도 클라이언트는 400과 동일하게 처리하도록 규정
+- 401 Unauthorized: 지정한 리소스에 대한 액세스 권한이 없다, 응답 헤더 WWW-Authenticate에 필요한 인증 방식을 지정함
+- 402 Payment Required: 지정한 리소스를 액세스하기 위해서는 결제가 필요하다
+- 403 Forbidden: 지정한 리소스에 대한 액세스가 금지되었다, 401 인증 처리 이외의 사유로 리소스에 대한 액세스가 금지되었음을 의미
+- 404 Not Found: 지정한 리소스를 찾을 수 없다
+- 405 Method Not Allowed: 요청한 URI가 지정한 메소드를 지원하지 않는다.
+
+## 서버 에러
+5XX로 시작, 서버 사정으로 메시지 처리에 문제가 발생한 경우, 서버의 부하, DB 처리 과정 오류, 서버에서 익셉션이 발생하는 경우를 의미
+- 500 Internal Server Error: 서버에 에러가 발생하였다/클라이언트가 모르는 5xx 계열의 응답 코드가 반환된 경우에도 클라이언트는 500과 동일하게 처리하도록 규정함
+- 501 Not Implemented: 요청한 URI의 메소드에 대해 서버가 구현하고 있지 않음
+- 502 Bad Gateway: 게이트웨이 또는 프록시 역할을 하는 서버가 그 뒷단의 서버로부터 잘못된 응답을 받음