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

mission1/WIL.md

@@ -0,0 +1,143 @@
+# 프론트엔드 백엔드 연결
+## 프론트엔드와 백엔드는 어떻게 구분될까?
+
+**프론트엔드**
+
+- 사용자 인터페이스: 프론트엔드는 사용자가 직접 상호작용하는 부분입니다. 웹 페이지의 레이아웃, 디자인, 인터랙션 등을 담당합니다.
+- 테크놀로지: HTML, CSS, JavaScript 등의 언어와 라이브러리(예: React, Angular, Vue.js) 또는 프레임워크를 사용합니다.
+- 클라이언트 측: 프론트엔드 코드는 사용자의 브라우저에서 실행됩니다.
+- 데이터 표시: 프론트엔드는 백엔드에서 받은 데이터를 사용자에게 표시하고, 사용자의 입력을 백엔드로 전달합니다.
+
+**백엔드**
+- 서버와 데이터 처리: 백엔드는 데이터베이스와 서버 로직을 관리합니다. 데이터의 CRUD(Create, Read, Update, Delete) 작업을 담당하며, 비즈니스 로직을 처리합니다.
+- 테크놀로지: 백엔드 개발에는 Python (Django, Flask), JavaScript (Node.js), Java (Spring), Ruby (Ruby on Rails), PHP (Laravel) 등 다양한 언어와 프레임워크가 사용됩니다.
+- 서버 측: 백엔드 코드는 서버에서 실행됩니다. 서버는 클라이언트의 요청을 받아 적절한 응답을 제공합니다.
+- 데이터 저장: 대게 RDBMS(예: MySQL, PostgreSQL)나 NoSQL(예: MongoDB, Cassandra) 데이터베이스를 사용해 데이터를 저장하고 관리합니다.
+
+## 프론트엔드와 백엔드 연결 원리
+
+- HTTP 프로토콜: 프론트엔드와 백엔드는 대개 HTTP(HyperText Transfer Protocol)를 통해 통신합니다.
+- API (Application Programming Interface): 백엔드 서버는 특정 엔드포인트를 통해 데이터나 기능을 제공하며, 프론트엔드는 이 엔드포인트에 요청을 보내 데이터를 받거나 처리합니다.
+- 비동기 통신: 현대 웹 앱에서는 AJAX(Asynchronous JavaScript and XML)나 Fetch API, Axios 등을 사용하여 비동기적으로 데이터를 주고 받습니다.
+
+## 프론트엔드와 백엔드 연결 방법
+
+- RESTful API: 가장 일반적인 방법으로, 백엔드에서 RESTful 원칙을 따르는 API를 제공하고, 프론트엔드에서는 이 API를 호출합니다. 예: GET /users, POST /users
+- GraphQL: 요즘 많이 사용되는 새로운 기술로, 프론트엔드에서 필요한 데이터 형식을 지정하여 요청할 수 있습니다.
+-  WebSocket: 실시간 통신이 필요한 경우 사용되며, HTTP보다 더 빠른 양방향 통신을 지원합니다.
+- Server-Sent Events (SSE): 서버에서 클라이언트로 실시간으로 데이터를 전송할 때 사용됩니다.
+
+# HTTP 요청 메소드
+HTTP는 요청 메서드를 정의하여, 주어진 리소스에 수행하길 원하는 행동을 나타낸다. 간혹 요청 메서드를 "HTTP 동사"라고 부르기도 한다. 각각의 메서드는 서로 다른 의미를 구현하지만, 일부 기능은 메서드 집합 간에 서로 공유하기도 한다.
+
+## GET
+특정한 리소스를 가져오도록 요청한다. `GET` 요청은 데이터를 가져올 때만 사용해야 한다.
+        `GET` 요청에 본문이나 페이로드가 담겨있으면 명세에는 금지되어있지 않지만, 의미가 정의되지 않아 기존에 존재하는 구현체에게 요청을 거부당할수 있다. 이러한 이유로 `GET` 요청에는 본문이나 페이로드를 담지 않는 것이 바람직하다.
+
+## HEAD
+특정 리소스를 `GET` 메서드로 요청했을 때 돌아올 헤더를 요청한다.
+
+`HEAD` 메서드에 대한 응답은 본문을 가져선 안되며, 본문이 존재하더라도 무시해야 한다.
+그러나, `Content-Length`처럼 본문 콘텐츠를 설명하는 개체 헤더는 포함할 수 있다. 이 때, 개체 헤더는 비어있어야 하는 `HEAD`의 본문과는 관련이 없고, 대신 `Get`메서드로 동일한 리소스를 요청했을 때의 본문을 설명한다.
+
+## POST
+서버로 데이터를 전송한다. 요청 본문의 유형은 `Content-Type` 헤더로 나타낸다.
+
+`PUT`과 `POST`의 차이는 멱등성으로, `PUT`은 멱등성을 가진다. `PUT`은 한 번을 보내도, 여러 번을 연속으로 보내도 같은 효과를 보인다. 즉, 부수 효과(side effect)가 없다.
+
+`POST` 요청은 보통 HTML 양식을 통해 서버에 전송하며, 서버에 변경사항을 만든다. 이 경우의 콘텐츠 유형(`Content-Type`)은 `<form>` 요소의 `enctype` 특성이나 `<input>`, `<button>` 요소의 `formenctpe` 특성 안에 적당한 문자열을 넣어 결정한다.
+
+`POST` 요청을 HTML 양식 외의 다른 방법 (`XMLHttpRequest` 등)으로 전송할 땐 요청의 본문이 어떤 형태도 취할 수 있다. HTTP 1.1 규격에 정의된 바와 같이, `POST`는 다음의 기능을 포함하는 균일한 메서드를 허용하도록 설계되었다.
+
+- 기존 리소스에 주석달기
+- 게시판, 뉴스 그룹, 메일링 리스트나 이와 유사한 시스템에 글 올리기
+- 회원가입 모달로 새로운 사용자 추가하기
+- 양식 전송 결과 등 데이터 블록을 데이터 처리 프로세스에 보내기
+- 이어붙이기 연산을 통한 데이터베이스 확장
+
+## PUT
+요청 페이로드를 사용해 새로운 리소스를 생성하거나, 대상 리소스를 나타내는 데이터를 대체한다.
+
+`PUT`과 `POST`의 차이는 [여기](#post)
+
+## DELETE
+지정한 리소스를 삭제한다.
+
+## CONNECT
+HTTP `CONNECT` 메소드는 요청한 리소스에 대해 양방향 연결을 시작하는 메소드이다. 이는 터널을 열기 위해서 사용될 수 있다.
+
+`CONNECT` 메소드는 SSL (HTTPS)를 사용하는 웹사이트에 접속하는데 사용될 수 있다.
+
+## PATCH
+리소스의 부분적인 수정을 할 때에 사용된다.
+
+`PUT` 메소드는 문서 전체의 완전한 교체만을 허용한다. 반면 `PATCH` 메소드는 `PUT` 메소드와 달리 멱등성을 가지지 않는데, 이는 동일한 patch 요청이 다른 결과를 야기할 수도 있음을 뜻한다. 하지만 PATCH를 PUT과 같은 방식으로 사용함으로써 멱등성을 가지게 할 수도 있다.
+
+`PATCH` (혹은 `PUT`)는 다른 리소스에게 부수효과(side-effects)를 일으킬 가능성이 있다.
+
+# HTTP 상태코드
+## 정보 응답
+### 100 Continue
+이 임시적인 응답은 지금까지의 상태가 괜찮으며 클라이언트가 계속해서 요청을 하거나 이미 요청을 완료한 경우에는 무시해도 되는 것을 알려준다.
+
+### 101 Switdcing Protocol
+이 코드는 클라이언트가 보낸 `Upgrade` 요청 헤더에 대한 응답에 들어가며 서버에서 프로토콜을 변경할 것임을 알려준다.
+
+### 102 Processing
+이 코드는 서버가 요청을 수신하였으며 이를 처리하고 있지만, 아직 제대로 된 응답을 알려줄 수 없음을 알려준다.
+
+### 103 Early Hints
+이 상태 코드는 주로 `Link` 헤더와 함께 사용되어 서버가 응답을 준비하는 동안 사용자 에이전트가(user agent) 사전 로딩(preloading)을 시작할 수 있도록 한다.
+
+## 성공 응답
+### 200 OK
+요청이 성공적으로 되었다. 성공의 의미는 HTTP 메소드에 따라 달라진다.
+- GET: 리소스를 불러와서 메시지 바디에 전송되었다.
+- HEAD: 개체 헤더가 메시지 바디에 있다.
+- PUT 또는 POST: 수행 결과에 대한 리소스가 메시지 바디에 전송되었다.
+- TRACE: 메시지 바디는 서버에서 수신한 요청 미시지를 포함하고 있다.
+
+### 201 Created
+요청이 성공적이었으며 그 결과로 새로운 리소스가 생성되었다. 이 응답은 일반적으로 POST 요청 또는 일부 PUT 요청 이후에 따라온다.
+
+### 202 Accepted
+요청을 수신하였지만 그에 응하여 행동할 수 없다. 이 응답은 요청 처리에 대한 결과를 이후에 HTTP로 비동기 응답을 보내는 것에 대해서 명확하게 명시하지 않는다. 이것은 다른 프로세스에서 처리 또는 서버가 요청을 다루고 있거나 배치 프로세스를 하고 있는 경우를 위해 만들어졌다.
+
+## 리다이렉션 메시지
+### 300 Multiple Choice
+요청에 대해서 하나 이상의 응답이 가능하다. 사용자 에이전트 또는 사용자는 그중에 하나를 반드시 선택해야한다. 응답 중 하나를 선택하는 방법에 대한 표준화 된 방법은 존재하지 않는다.
+
+### 301 Moved Permanently
+이 응답 코드는 요청한 리소스의 URI가 변경되었음을 의미한다. 새로운 URI가 응답에서 아마도 주어질 수 있다.
+
+### 303 See Other
+클라이언트가 요청한 리소스를 다른 URI에서 HET 요청을 통해 얻어야 할 때, 서버가 클라이언트로 직접 보내는 응답이다.
+
+### 307 Temporary Redirect
+클라이언트가 요청한 리소스가 다른 URI에 있으며, 이전 요청과 동일한 메소드를 사용하여 요청해야할 때, 서버가 클라이언트에 이 응답을 직접 보낸다. 이것은 `302 Found` HTTP 응답 코드와 동일한 의미를 가지고 있으며, 사용자 에이전트가 반드시 사용된 HTTP 메소드를 변경하지 말아야 하는 점만 다르다: 만약 첫 요청에 `POST`가 사양되었다면, 두번째 요청도 반드시 `POST`를 사용해야 한다.
+
+## 클라이언트 에러 응답
+### 400 Bad Request
+이 응답은 잘못된 문법으로 인하여 서버가 요청을 이해할 수 없음을 의미한다.
+
+### 401 Unauthorized
+비록 HTTP 표준에서는 "미승인(unauthorized)"를 명확히 하고 있지만, 의미상 이 응답은 "비인증(unauthenticated)"을 의미한다. 클라이언트는 요청한 응답을 받기 위해서는 반드시 스스로를 인증해야 한다.
+
+### 403 Forbidden
+클라이언트는 콘텐츠에 접근할 권리를 가지고 있지 않다. 예를 들어 그들은 미승인이어서 서버는 거절을 위한 적절한 응답을 보낸다. 401과 다른 점은 서버가 클라이언트가 누구인지 알고 있다.
+
+### 404 Not Found
+서버는 요청받은 리소스를 찾을 수 없다. 브라우저에서는 알려지지 않은 URL을 의미한다. 이것은 API에서 종점은 적절하지만 리소스 자체는 존재하지 않음을 의미할 수도 있다. 서버들은 인증받지 않은 클라이언트로부터 리소스를 숨기기 위하여 이 응답을 403 대신에 전송할 수도 있다. 이 응답 코드는 웹에서 반복적으로 발생하기 때문에 가장 유명할지도 모른다.
+
+## 서버 에러 응답
+### 500 Internal Server Error
+서버가 처리 방법을 모르는 상황이 발생했다. 서버는 아직 처리 방법을 알 수 없다.
+
+### 501 Not Implemented
+요청 방법은 서버에서 지원되지 않으므로 처리할 수 없다. 서버가 지원해야 하는 유일한 방법은 `GET`와 `HEAD`이다. 이 코드는 반환하면 안된다.
+
+### 502 Bad Gateway
+이 오류 응답은 서버가 요청을 처리하는 데 필요한 응답을 얻기 위해 게이트웨이로 작업하는 동안 잘못된 응답을 수신했음을 의미한다.
+
+
+참고 <https://developer.mozilla.org/ko/docs/Web/HTTP>