HTTP 에러 메시지

1xx (조건부 응답) : 요청을 받았으며 작업을 계속한다.
2xx (성공) : 이 클래스의 상태 코드는 클라이언트가 요청한 동작을 수신하여 이해했고 승낙했으며 성공적으로 처리했음을 가리킨다.
3xx (리다이렉션 완료) : 클라이언트는 요청을 마치기 위해 추가 동작을 취해야 한다.
4xx (요청 오류)(클라이언트 오류) : 4xx 클래스의 상태 코드는 클라이언트에 오류가 있음을 나타낸다.
5xx (서버 오류) : 서버가 유효한 요청을 명백하게 수행하지 못했음을 나타낸다.

프로토콜

프로토콜은 컴퓨터 내부에서, 또는 컴퓨터 사이에서 데이터의 교환 방식을 정의하는 규칙 체계입니다. 기기 간 통신은 교환되는 데이터의 형식에 대해 상호 합의를 요구합니다. 이런 형식을 정의하는 규칙의 집합을 프로토콜이라고 합니다. 

간단히 예를 들면 '1'과 '2'라는 데이터를 보낼 때도   이진법(컴퓨터는 당연히 이진법)으로 16bit를 사용해서 데이터를 주고 받자라고 미리 약속을 합니다.

그러고 나서 약속한대로 0000 0000 0000 0001   /  0000 0000 0000 0010   를 보내면 이를 받는 쪽에서도 당연히 16bit로 왔다는걸 알고 '1'과 '2'라고 인식하는 것입니다.  

HTTP 프로토콜이란?

HTTP(Hypertext Transfer Protocol)는 웹을 개발하는 사람이라면 누구나 다 알아야 하는 통신 프로토콜입니다.

웹에서는 브라우저와 서버 간에 데이터를 주고받기 위한 방식으로 HTTP 프로토콜을 사용하고 있습니다.

HTTP 요청과 응답

웹 뿐만 아니라 server-client 관계에서는  client가 요청(request)하면 서버가 요청을 처리한 후 client에게 응답(response)합니다.  단지 웹에서는 이 요청과 응답을 HTTP 방식으로 요청하고 응답하기로 한 것입니다.

HTTP 프로토콜로 데이터를 주고받기 위해서는 아래와 같이 요청(Request)을 보내고 응답(Response)을 받아야 합니다.

HTTP통신에서의 client는 브라우저(크롬,exploer 등)이 되고

server는 저희가 아는 WAS(톰캣, ZEUS 등)이 되는 것입니다.    

Http Request Message의 구조

크게 3부분으로 구성된다.

• start line(request line) : Http request의 첫 라인으로써, 3 부분으로 구성된다
  • HTTP Method: GET, POST 등 action을 정의.
  • Request target: request가 전송되는 uri (endpoint)
  • HTTP Version
  GET /doc/test/html HTTP/1.1
• headers : request에 대한 meta정보를 담고 있으며, key:value 값으로 되어있다.
  • Host : 요청이 전송되는 target의 host url: 예를 들어, google.com
  • User-Agent : 요청을 보내는 클라이언트의 대한 정보: 사용하는 웹 브라우저와 버전, OS 등
  • Accept : 해당 요청이 받을 수 있는 응답(response) 타입.
    (조건부 요청을 허용: (accept-, If-), 모든 요청 허용:(/))
  • Connection : 해당 요청이 끝난후에 클라이언트와 서버가 계속해서 네트워크 컨넥션을 유지 할것인지 아니면 끊을것인지에 대해 지시하는 부분. (Keep-alive or cancel)
  • Content-Type : 해당 요청이 보내는 메세지 body의 타입. 예를 들어, JSON을 보내면 application/json.
  • Content-Length :메세지 body의 길이

• empty line: 요청에 대한 meta 정보가 전송되었음을 알린다.
• body:
  • 해당 request의 실제 메세지/내용이 들어있다.
  • XML 이나 JSON 데이터가 들어갈 수 있다.
  • GET은 body가 대부분 없다.
  실제 예시:
  

  

Http Response Message의 구조

기본적인 구조는 request와 비슷하다.

• status line : response의 상태를 간략하게 나타내며, 3부분으로 구성되어 있다
  
  • HTTP version  
  • status code : 응답 상태를 나타내는 코드
  • status text : 응답 상태의 설명 (ex: Not Found)
• headers :
  • request의 header와 동일하다
  • response에서만 사용되는 header 값이 있다 (예: User-Agent가 없고, Server가 있음).
• empty line
• body : 실제 응답하는 데이터를 나타낸다. status 2XX의 경우, 존재하지 않는 경우가 많다.

response header의 예시:

URL

URL(Uniform Resource Locators)은 개발자가 아니더라도 이미 우리에게 익숙한 용어입니다. 서버에 자원을 요청하기 위해 입력하는 영문 주소죠. 아무래도 숫자로 되어 있는 IP 주소보다는 훨씬 기억하기 쉽기 때문에 사용하는 것 같습니다.

URL 구조는 아래와 같습니다.

이 때 브라우저 주소창에 URL을 입력하면 해당 주소(host)에 맞는  서버컴퓨터로 가게되고 

포트(port)를 통해  서버컴퓨터의  특정 WAS로 가게되고  나머지 resource path를 통해  특정 페이지까지 요청이 됩니다.

예를 들면 http://localhost:8080/study/01basic/00hello.jsp

또는 http://192.168.0.76:8080/study/01basic/00hello.jsp를 

브라우저에서 입력하면  localhost나 192.168.0.76(현재 내 컴퓨터 내부 ip주소)을 통해 자기 컴퓨터에 가고

8080포트를 통해  내 컴퓨터의 톰캣으로 가게됩니다. (이 때 내 컴퓨터의 톰캣이 켜져있어야 합니다)

그리고 나머지 resource path를 통해 00hello.jsp까지 간다면  톰캣이  해당 요청을 처리해 응답하면 

브라우저는 응답을 받아 00hello.jsp의 화면을 보여주게 되는 식입니다.

글 마지막에 이미지를 보면 좀 더 이해하기 쉬울것입니다.

HTTP 요청 메서드

앞에서 살펴본 URL을 이용하면 서버에 특정 데이터를 요청할 수 있습니다. 여기서 요청하는 데이터에 특정 동작을 수행하고 싶으면 어떻게 해야 할까요? 바로 HTTP 요청 메서드(Http Request Methods)를 이용합니다.

일반적으로 HTTP 요청 메서드는 HTTP Verbs라고도 불리우며 아래와 같이 주요 메서드를 갖고 있습니다.

• GET : 존재하는 자원에 대한 요청
• POST : 새로운 자원을 생성
• PUT : 존재하는 자원에 대한 변경
• DELETE : 존재하는 자원에 대한 삭제

이와 같이 데이터에 대한 조회, 생성, 변경, 삭제 동작을 HTTP 요청 메서드로 정의할 수 있습니다.

PUT,DELETE도 post방식으로 가능합니다.

사실 대부분 GET,POST방식만 사용합니다.

HTTP 상태 코드

앞에서 살펴본 URL과 요청 메서드가 클라이언트에서 설정해야 할 정보라면 HTTP 상태 코드(HTTP Status Code)는 서버에서 설정해주는 응답(Response) 정보입니다.

프런트엔드 개발자 입장에서는 더욱이 중요한 이유가 이 상태 코드로 에러 처리를 할 수 있기 때문입니다. 간단한 예시를 들어 아래와 같이 사용자 목록을 받아오는 GET 메서드 요청을 날려보겠습니다.

http://domain.com/users

위 요청을 보내고 나면 서버에서 응답으로 오는 상태 코드가 크게 2개로 나뉩니다. 200(성공)과 404(실패)입니다. 따라서, 이 HTTP 상태 코드로 추가적인 로직을 구현할 수 있죠.

주요 상태 코드는 200번대부터 500번대까지 다양하게 있지만 주요한 상태 코드만 몇 개 살펴보겠습니다.

2xx - 성공

200번대의 상태 코드는 대부분 성공을 의미합니다.

• 200 : GET 요청에 대한 성공
• 204 : No Content. 성공했으나 응답 본문에 데이터가 없음
• 205 : Reset Content. 성공했으나 클라이언트의 화면을 새로 고침하도록 권고
• 206 : Partial Conent. 성공했으나 일부 범위의 데이터만 반환

3xx - 리다이렉션

300번대의 상태 코드는 대부분 클라이언트가 이전 주소로 데이터를 요청하여 서버에서 새 URL로 리다이렉트를 유도하는 경우입니다.

• 301 : Moved Permanently, 요청한 자원이 새 URL에 존재
• 303 : See Other, 요청한 자원이 임시 주소에 존재
• 304 : Not Modified, 요청한 자원이 변경되지 않았으므로 클라이언트에서 캐싱된 자원을 사용하도록 권고. ETag와 같은 정보를 활용하여 변경 여부를 확인

4xx - 클라이언트 에러

400번대 상태 코드는 대부분 클라이언트의 코드가 잘못된 경우입니다. 유효하지 않은 자원을 요청했거나 요청이나 권한이 잘못된 경우 발생합니다. 가장 익숙한 상태 코드는 404 코드입니다. 요청한 자원이 서버에 없다는 의미죠.

• 400 : Bad Request, 잘못된 요청
• 401 : Unauthorized, 권한 없이 요청. Authorization 헤더가 잘못된 경우
• 403 : Forbidden, 서버에서 해당 자원에 대해 접근 금지
• 405 : Method Not Allowed, 허용되지 않은 요청 메서드
• 409 : Conflict, 최신 자원이 아닌데 업데이트하는 경우. ex) 파일 업로드 시 버전 충돌

5xx - 서버 에러

500번대 상태 코드는 서버 쪽에서 오류가 난 경우입니다.

• 501 : Not Implemented, 요청한 동작에 대해 서버가 수행할 수 없는 경우
• 503 : Service Unavailable, 서버가 과부하 또는 유지 보수로 내려간 경우

다시 살펴보는 HTTP 요청과 응답

앞에서 배운 URL, 요청 메서드, 상태 코드를 조합하면 아래와 같은 구조가 나옵니다.

참고 : https://joshua1988.github.io/web-development/http-part1/#http-%ED%94%84%EB%A1%9C%ED%86%A0%EC%BD%9C-%ED%8A%B9%EC%A7%95

HTTP 메소드 중 GET방식과 POST 방식 차이

get방식이든 post방식이든 둘 다 브라우저가 서버에 요청하는 것입니다.

GET 방식

GET은 요청을 전송할 때 필요한 데이터를 Body에 담지 않고, 쿼리스트링을 통해 전송합니다.

URL의 끝에 ?와 함께 이름과 값으로 쌍을 이루는 요청 파라미터를 쿼리스트링이라고 부릅니다. 만약, 요청 파라미터가 여러 개이면 &로 연결합니다. 쿼리스트링을 사용하게 되면 URL에 조회 조건을 표시하기 때문에 특정 페이지를 링크하거나 북마크할 수 있습니다.

쿼리스트링을 포함한 URL의 샘플은 아래와 같습니다. 여기서 요청 파라미터명은 name1, name2이고, 각각의 파라미터는 value1, value2라는 값으로 서버에 요청을 보내게 됩니다.

www.example-url.com/resources?name1=value1&name2=value2

그리고 GET은 불필요한 요청을 제한하기 위해 요청이 캐시될 수 있습니다. js, css, 이미지 같은 정적 컨텐츠는 데이터양이 크고, 변경될 일이 적어서 반복해서 동일한 요청을 보낼 필요가 없습니다. 정적 컨텐츠를 요청하고 나면 브라우저에서는 요청을 캐시해두고, 동일한 요청이 발생할 때 서버로 요청을 보내지 않고 캐시된 데이터를 사용합니다. 그래서 프론트엔드 개발을 하다보면 정적 컨텐츠가 캐시돼 컨텐츠를 변경해도 내용이 바뀌지 않는 경우가 종종 발생합니다. 이 때는 브라우저의 캐시를 지워주면 다시 컨텐츠를 조회하기 위해 서버로 요청을 보내게 됩니다.
(이게 바로 f12누르고 새로고침 오른쪽 누르는 거)

• GET 요청은 캐시가 가능하다. 
•  : GET을 통해 서버에 리소스를 요청할 때 웹 캐시가 요청을 가로채 서버로부터 리소스를 다시 다운로드하는 대신 리소스의 복사본을 반환한다. HTTP 헤더에서 cache-control 헤더를 통해 캐시 옵션을 지정할 수 있다.
• GET 요청은 브라우저 히스토리에 남는다.
• GET 요청은 길이 제한이 있다.
• GET 요청은 중요한 정보를 다루면 안된다. (보안)

POST 방식

POST는 리소스를 생성/변경하기 위해 설계되었기 때문에 GET과 달리 전송해야될 데이터를 HTTP 메세지의 Body에 담아서 전송합니다. HTTP 메세지의 Body는 길이의 제한없이 데이터를 전송할 수 있습니다. 그래서 POST 요청은 GET과 달리 대용량 데이터를 전송할 수 있습니다. 이처럼 POST는 데이터가 Body로 전송되고 내용이 눈에 보이지 않아 GET보다 보안적인 면에서 안전하다고 생각할 수 있지만, POST 요청도 크롬 개발자 도구, Fiddler와 같은 툴로 요청 내용을 확인할 수 있기 때문에 민감한 데이터의 경우에는 반드시 암호화해 전송해야 합니다.

그리고 POST로 요청을 보낼 때는 요청 헤더의 Content-Type에 요청 데이터의 타입을 표시해야 합니다.

Content-Type의 종류로는 application/x-www-form-urlencoded, text/plain, multipart/form-data 등이 있다

데이터 타입을 표시하지 않으면 서버는 내용이나 URL에 포함된 리소스의 확장자명 등으로 데이터 타입을 유추합니다. 만약, 알 수 없는 경우에는 application/octet-stream로 요청을 처리합니다.

• POST 요청은 캐시되지 않는다.
• POST 요청은 브라우저 히스토리에 남지 않는다.
• POST 요청은 데이터 길이에 제한이 없다.

GET 과 POST 의 차이점 

 GET과 POST의 특징만 보아도 차이가 나긴하지만 추가적으로 차이점을 정리해보면 다음과 같다.

• 사용목적 : GET은 서버의 리소스에서 데이터를 요청할 때, POST는 서버의 리소스를 새로 생성하거나 업데이트할 때 사용한다.
• DB로 따지면 GET은 SELECT 에 가깝고, POST는 Create 에 가깝다고 보면 된다.
• 요청에 body 유무 : GET 은 URL 파라미터에 요청하는 데이터를 담아 보내기 때문에 HTTP 메시지에 body가 없다. POST 는 body 에 데이터를 담아 보내기 때문에 당연히 HTTP 메시지에 body가 존재한다.
  
  
• 멱등성 (idempotent) : GET 요청은 멱등이며, POST는 멱등이 아니다.

멱등이란?

멱등의 사전적 정의는 연산을 여러 번 적용하더라도 결과가 달라지지 않는 성질을 의미한다.

GET은 리소스를 조회한다는 점에서 여러 번 요청하더라도 응답이 똑같을 것 이다. 반대로 POST는 리소스를 새로 생성하거나 업데이트할 때 사용되기 때문에 멱등이 아니라고 볼 수 있다. (POST 요청이 발생하면 서버가 변경될 수 있다.)

출처:https://brilliantdevelop.tistory.com/33

form이란?

사용자가 입력한 데이터(입력값)를 서버로 보내기 위해 사용하는 태그.

서버란? 정보를 제공하는 호스트(host)이다!

서버와 클라이언트

클라이언트(사용자)가 요청을 하면, 서버는 그에 대한 응답으로 정보를 제공한다!
1. 클라이언트 : (네이버 홈페이지 주소를 입력) 네이버 홈페이지 보여주세요!(요청)
2. 서버 : 네. 홈페이지 html문서를 보내드릴테니 보세요!
(응답으로 네이버 웹페이지를 보냄)
3. 클라이언트 : 네!! 제 웹 브라우저에 네이버 홈페이지가 오픈됐어요! 감사합니다~

클라이언트가 어떤 요청을 보내는가에 따라, 응답은 달라질 수 있다!

로그인 예시

클라이언트 : 로그인 시켜주세요! 로그인버튼 클릭!(요청)
서버 : 네! 앗! 근데 비밀번호가 틀려요!(응답)
클라이언트 : 앗 그렇군요!

로그인 양식은 세 개의 입력 요소(아이디, 비밀번호, 로그인버튼)로 구성되어 있으며, 입력 데이터는 form을 통해 서버로 전송(submit)된다!

form태그

form은 입력 요소들을 감싸며, 입력 값을 서버 측으로 제출(submit)할 수 있다.

<form>
    <input type="text" placeholder="아이디">
    <br>
    <input type="text" placeholder="비밀번호">
</form>

form값 서버로 보내기

form의 내용(입력값)을 보내기 위해 input 태그의 submit 타입 사용 가능!

<form>
    <input type="text" placeholder="아이디">
    <br>
    <input type="text" placeholder="비밀번호">
    <br>
    <input type="submit" placeholder="로그인">
</form>

'로그인'버튼을 누르면 입력된 아이디와 비밀번호가 서버로 전송되고(요청)
서버 측에서 데이터를 처리한 결과를 클라이언트에게 보내준다(응답)

form의 속성

• action : 입력값을 전송할 서버의 URL
• method : 클라이언트가 입력한 데이터를 어떤 식으로 전송할지
  (GET or POST)

<form action="example.php" method="POST"></form>

위 예시코드는 example.php라는 서버 프로그램으로 입력값을 POST방식으로 전송할 것이다. 라는 내용이다.

GET VS POST

• GET : 서버에 요청을 보내어 응답을 받아낸다.
  서버로부터 정보를 '가져오겠다'는 성격의 요청이다.
• POST : 서버에 요청을 보내어 작업을 수행한다.
  서버에 있는 데이터를 추가/수정/삭제 한 후에 응답을 받아낸다.
  서버의 정보를 '조작하겠다'는 성격의 요청이다.GET은 값을 URL끝에 붙여 이동하고
  POST는 BODY에 값을 담아 이동해 URL에 보이지 않는다!
  -GET : url에 값이 보여 보안이 좋지 않아 단순요청을 할 때 사용
  -POST : url에 값이 안보여 보안이 좋아 서버의 정보를 조작할때 사용

내용정리

• form은 사용자가 입력 요소에 입력한 데이터를 서버로 전송해준다.
• 서버란 데이터를 제공하는 호스트이다.
• 클라이언트란 데이터를 제공받아 이용하는 고객(사용자)이다.
• form은 입력요소(input, select, textarea 등)를 감싸고,
  데이터를 제출(submit)한다.
• form의 action은 서버 측 주소를 지정하는 속성이다.
• form의 method는 데이터 전송 방식을 지정하는 속성이다.

출처:https://velog.io/@ybj1227/form%EC%97%90-%EB%8C%80%ED%95%B4

Dynamic Web Project(다이나믹 웹 프로젝트)는 Java Servlet(서블릿) 기반의 웹 애플리케이션입니다.

​

Servlet(서블릿)은 웹 브라우저(Web Browser)에서 요청(Request)이 들어오면 웹 컨테이너(Web Container, Servlet Container)에서 웹 페이지를 동적으로 생성하고 웹 브라우저에 응답(Respone)하는 Server-Side(서버사이드) 자바 프로그램입니다.

웹 서버(Web Server, HTTP Server)는 웹 브라우저(Web Browser)에서 HTTP 요청(Request)을 받아 정적인 콘텐츠(html, image(jpg, gif, png 등등), css, script)를 응답(Response)합니다.

웹 서버로는 Apache Server, Nginx, IIS, WebToB 등이 많이 사용됩니다.

​

Web Container(웹 컨테이너)는 요청되는 URL과 매핑되는 서블릿을 호출하기 위해 스레드를 생성하고 서블릿을 처리합니다. (WAS가 처리하는 것이 Web Container입니다. 설명을 위해 표시한 겁니다.)

그리고 Web Container(웹 컨테이너)는 서브릿뿐만 아니라 JSP 그리고 Server-Side(서버사이드) 코드가 있는 프로그램 파일들을 관리하고 처리합니다.

웹 응용프로그램 서버로는 Apache Tomcat, Web Logic, Web Sphere, JBOSS, Jeus 등이 많이 사용됩니다.

​

JSP vs Servlet     :차이점  https://thecodelab.tistory.com/77

JSP(Java Server Pages)는 Java를 이용한 Server-Side 스크립트 언어로 HTML 안에 Scriptlet(스크립틀릿)으로 자바 소스 코드(<% %>)를 포함하고 있습니다. 파일 확장자는 ".jsp"이고 WAS에서 실행될 때 동적으로 javax.servlet.http.HttpServlet 클래스를 상속받은 Java 소스 코드로 변환되고 컴파일(Compile)되어 실행됩니다. 이처럼 JSP 파일을 Servlet 클래스로 변환하고 실행시켜 주는 역할을 하는 프로그램을 Servlet Container (서블릿 컨테이너)라고 합니다.

​Servlet(서블릿)은 Java를 이용해 웹 페이지를 동적으로 생성하는 Server-Side 프로그램(Java 클래스)로 자바 소스 코드 안에 HTML를 포함하고 있습니다. 파일 확장자는 ".java"이고 배포하기 위해서는 컴파일(Compile)을 해야 합니다. 컴파일된 파일 확장자는 ".class"입니다.

출처:https://carrotweb.tistory.com/

Servlet과 JSP의 개념
기능의 차이는 없고 역할의 차이만 있다. (하는 일은 동일)

Servlet이란
웹 기반의 요청에 대한 동적인 처리가 가능한 Server Side에서 돌아가는 Java Program
Java 코드 안에 HTML 코드 (하나의 클래스)
웹 개발을 위해 만든 표준
구체적인 내용은 https://gmlwjd9405.github.io/2018/10/28/servlet.html 참고

JSP란
Java 언어를 기반으로 하는 Server Side 스크립트 언어
HTML 코드 안에 Java 코드
Servlet를 보완하고 기술을 확장한 스크립트 방식 표준
Servlet의 모든 기능 + 추가적인 기능

구체적인 내용은 https://gmlwjd9405.github.io/2018/11/03/jsp.html 참고
Servlet과 JSP의 차이
Servlet
Java 코드 안에 HTML 코드 (하나의 클래스)
data processing(Controller)에 좋다.
즉 DB와의 통신, Business Logic 호출, 데이터를 읽고 확인하는 작업 등에 유용하다.
Servlet이 수정된 경우 Java 코드를 컴파일(.class 파일 생성)한 후 동적인 페이지를 처리하기 때문에 전체 코드를 업데이트하고 다시 컴파일한 후 재배포하는 작업이 필요하다. (개발 생산성 저하)
JSP
HTML 코드 안에 Java 코드
presentation(View)에 좋다.
즉 요청 결과를 나타내는 HTML 작성하는데 유용하다.
JSP가 수정된 경우 재배포할 필요가 없이 WAS가 알아서 처리한다. (쉬운 배포)
Servlet과 JSP의 예시

Servlet

import java.io.*;
import javax.servlet.*;
import javax.servlet.http.*;

public ThreeParams extends HttpServlet {
    public void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
        
        response.setContentType("text/html");
        printWriter out = response.getWriter();
        
        String title = "Reading Three Request Parameters";
        String docType = "<!DOCTYPE html PUBLIC \"-//W3C//DTD HTML 4.01 Transitional//EN\">\n";
        
        out.println(docType + 
            "<HTML>\n" +
            "<HEAD><TITLE>" + title + "</TITLE></HEAD>\n" +
            "<BODY BGCOLOR=\"#FDF5E6\">\n" +  
            "<H1 ALIGN=\"CENTER\">" + title + "</H1>\n" + 
            "<UL>\n" + 
            "<LI><B>param1</B>: " + request.getParameter("param1") + "\n" +
            "<LI><B>param2</B>: " + request.getParameter("param2") + "\n" +
            "<LI><B>param3</B>: " + request.getParameter("param3") + "\n" +
            "</UL>\n" +
            "</BODY></HTML>");
        )
    }
}
https://gmlwjd9405.github.io/2018/11/04/servlet-vs-jsp.html

JSP

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<HTML>
<HEAD>
<TITLE>Reading Three Request Parameters</TITLE>
<LINK REL=STYLESHEET HREF="JSP-Styles.css" TYPE="text/css">
</HEAD>

<BODY>
<H1>Reading Three Request Parameters</H1>
<UL>
    <LI><B>param1</B>: <%= request.getParameter("param1") %>
    <LI><B>param2</B>: <%= request.getParameter("param2") %>
    <LI><B>param3</B>: <%= request.getParameter("param3") %>
</UL>
</BODY>
</HTML>

Servlet과 JSP의 관계
JSP만을 이용하는 모델

JSP가 사용자의 요청을 받아 Java Bean(DTO, DAO)을 호출하여 적절한 동적인 페이지를 생성한다.
동작 과정
JSP로 작성된 프로그램은 내부적으로 WAS에서 Servlet 파일로 변환
JSP 태그를 분해하고 추출하여 다시 순수한 HTML 웹 페이지로 변환
클라이언트로 응답
특징
개발 속도가 빠르다.
배우기 쉽다.
프레젠테이션 로직(View)과 비즈니스 로직(Controller)이 혼재한다.
JSP 코드가 복잡해져 유지 보수가 어려워진다.

JSP와 Servlet을 모두 이용하는 모델 (MVC Architecture)

JSP와 Servlet을 모두 사용하여 프레젠테이션 로직(View)과 비즈니스 로직(Controller)을 분리한다.
View(보여지는 부분)는 HTML이 중심이 되는 JSP를 사용
Controller(다른 자바 클래스에 데이터를 넘겨주는 부분)는 Java 코드가 중심이 되는 Servlet을 사용
Model은 Java Beans로, DTO와 DAO를 통해 Mysql과 같은 Data Storage에 접근
구체적인 MVC 패턴은 MVC-Architecture 참고
관련된 Post
Web Service의 기본적인 동작 과정과 Servlet에 대해 알고 싶으시면 Servlet 이란을 참고하시기 바랍니다.
JSP의 개념과 기본 문법에 대해 알고 싶으시면 JSP 란을 참고하시기 바랍니다.
Web Server와 WAS의 개념과 차이에 대해 알고 싶으시면 Web Server VS WAS를 참고하시기 바랍니다.
Web Application Structure과 web.xml 설정 내용, 역할 및 간단한 예시에 대해 알고 싶으시면 Web Application Structure 이해하기를 참고하시기 바랍니다.
References
http://anster.tistory.com/128
https://gmlwjd9405.github.io/2018/11/04/servlet-vs-jsp.html

## java와 jsp의 차이

```
JSP는 Java Server Pages의 약자이며, Java 웹 프로그래밍을 위해 사용되는 기술 중 하나입니다. JSP는 HTML과 Java 코드를 혼합하여 동적 웹 페이지를 생성합니다. JSP는 Java 언어를 기반으로 하기 때문에 Java와 비슷한 문법을 가지고 있습니다.

하지만 JSP와 Java는 몇 가지 차이점이 있습니다. JSP는 HTML과 Java 코드를 함께 작성하는 것이 가능하기 때문에, Java의 몇몇 기능을 JSP에서 사용할 수 없습니다. 예를 들어, JSP에서는 Java의 static 변수나 static 메소드를 직접 사용할 수 없습니다. 또한, JSP에서는 Java 코드를 스크립트릿(<% %>) 안에 작성해야 하며, 세미콜론을 생략할 수 없습니다.

또한, JSP에서는 HTML 태그를 사용하여 출력을 제어할 수 있으므로, Java에서는 없는 태그나 속성을 사용해야 할 때가 있습니다. 예를 들어, JSP에서는 jsp:include 태그를 사용하여 다른 JSP 파일을 포함할 수 있습니다. 또한, JSP에서는 표현식(<%= %>)을 사용하여 Java 코드의 결과를 HTML로 출력할 수 있습니다.
```

• 깃/깃허브 구분
  👉 Git : 버전 컨트롤 시스템(version control system).
  👉 Github : 원격 저장소(remote repository).
• 현재 깃허브에서 master라는 이름 대신 main 이름을 default로 해놓은 상태지만 사용자가 master로 수정하여 사용할 수 있음.
• 우측 상단 프로필 클릭 -> settings -> repositories -> Repository default branch에서 변경

깃허브 시작하기

• 깃허브 계정을 만든다.

• 깃허브에서 repository를 생성한다.(public = 전체공개 / private = 개인용)
• 커밋할 폴더에 들어가서 git init
• shell에 깃 설치 = brew install git (Mac OS)
• 토큰이나 ssh로 인증

📍깃헙 토큰 발행 방법

➡️ github 접속 및 가입
➡️ settings 
➡️ developer settings 
➡️ personal access tokens 
➡️ generate new tokens

✎ 토큰 설정 후 토큰 키를 복사한다음에 쉘에서 push할 때 비밀번호 작성하는 부분에 붙여넣어야 함

📍ssh key 설정 방법

shell에서 
$ ssh-keygen            //키 생성
$ cat ~/.ssh/id_rsa     //개인키
$ cat ~/.ssh/id_rsa.pub //공개키

✎ 이후 깃허브 프로필-세팅에서 ssh 공개키 등록

📍깃허브 push용 이름 및 이메일 세팅

$ git config --global user.name "username"
$ git config --global user.email "email@email.com"

✎ --global 옵션은 default로 전체 깃에 적용. 특정 프로젝트에서 이름 다르게 하려면 --global 옵션 빼고 하면 됨.

깃허브 활용

📍 기본

$ git add (파일명) 		// 특정 파일 Index(Staging area)에 추가
$ git add . 			 // 현재 및 하위 디렉토리 모든 파일 index 추가
$ git commit -m "(설명)"	// local repository에 추가
$ git push origin master // remote repository에 추가

📍 커밋 수정(amend)

로컬 저장소의 가장 마지막 커밋을 수정

git commit --amend -m "(설명)"
git commit --amend --no-edit //--no-edit 옵션은 설명 수정하지 않을 때

📍 버전확인

$ git --version

📍 커밋 이력 보기(log)

$ git log

이후 git checkout으로 시점을 변경하거나 reset 등으로 되돌리기 가능

📍 커밋 이력 보기2(reflog)

$ git reflog

HEAD@{idx} 이런식으로 모든 브랜치의 이력을 확인하고, reset을 하고 싶을 땐

git reset HEAD@{index}

으로 돌아가면 된다.
git log보다 압축적으로 로그 확인이 가능하다.

📍 커밋 메시지 변경

$ git commit --amend

입력하면 에디터가 열리면서 현재 커밋의 메시지를 수정할 수 있다.

커밋에 빠뜨린 파일 추가

아직 push를 하지 않은 상태에서 로컬 커밋에 파일 하나를 빠뜨렸다면,

$ git add [빠뜨린 파일]

이후에

$ git commit --amend --no-edit

이렇게 하면 빠뜨린 파일이 같이 커밋 된다.

📍 원격저장소 확인/연결

$ git remote -v

$ git remote add (이름) (url) // 원격저장소 추가

git init 이후 github에서 리포지토리 만든 뒤 (원격저장소) 연결 세팅

$git remote add origin [REPOSITORY ADDRESS]

REPOSITORY ADDRESS란,

https://github.com/[GITHUB USERNAME]/[REPOSITORY NAME].git
또는
git@github.com:[GITHUB USERNAME]/[REPOSITORY NAME].git

📍 브랜치 목록 보기

$ git fetch		  // 정보 업데이트
$ git branch  	  //local
$ git branch -a   //remote까지 확인

📍 파일 상태보기

$ git status

index(stage) 영역에 없으면 🟥빨간색 = add 안된 상태
index(stage) 영역에 있으면 🟩초록색 = add 된 상태

branch

📍 새 브랜치 만들기

$ git branch (브랜치명) 	   			   // 브랜치만 생성
$ git checkout (브랜치명)    			   // 해당 브랜치로 이동
$ git checkout -b (브랜치명) 			   // 현재 커밋에서 브랜치 생성하고 이동
$ git checkout (커밋아이디) -b (브랜치명)   //해당 커밋으로 이동 후 브랜치 생성

📍 마스터 브랜치로 돌아가기

$ git checkout master

📍 브랜치 목록 보기

$ git branch    //local
$ git branch -a //remote까지 확인

원격브랜치는 다음 명령어로도 확인 가능

git ls-remote origin

📍 브랜치 삭제

$ git branch -d (브랜치명) 			   //로컬 저장소에서 브랜치 삭제
$ git push origin --delete (브랜치명)    //원격저장소에서도 삭제

📍 main브랜치 이름 변경

git branch -m main master
git fetch origin
git branch -u origin/master master
git remote set-head origin -a

checkout과 reset

📍checkout

다른 커밋 보기로 커밋 이력은 그대로 있는 상태에서 현재 보는 시점을 변경.

$ git checkout (커밋아이디)  // 커밋아이디는 git log로 확인
$ git checkout master	  // 최근 커밋 상태로 돌아오기
$ git checkout (브랜치명)   // 해당 브랜치로 이동

📍reset

로컬저장소에서 이전 커밋으로 돌아가고 이후 커밋은 add는 안 한 상태(unstage)로 만들기.
워크 스페이스에 작업하던 내용은 그대로 있음.

$ git reset (커밋 아이디)
$ git reset HEAD^		//한 커밋 이전
$ git reset HEAD^^		//두 커밋 이전
$ git reset HEAD^^^		//세 커밋 이전

이전 커밋으로 돌아가면서 이후 커밋 삭제(하드 리셋)

$ git reset --hard (커밋 아이디)
$ git reset --hard HEAD^^

✎ 이후 원격 저장소에는 삭제가 반영되지 않은 상태이므로 강제 커밋

$ git push origin master --force

✎ checkout은 커밋은 그래로 두고 HEAD(시점)만 이동하고, reset은 삭제까지 한다는 차이가 있음.
✎ reset 대신 revert를 사용할 수 있는데, revert는 기준 커밋 이후로 삭제하는 것이 아니라 현재까지의 이력을 남겨두고 과거 커밋으로 재수정해 커밋한 효과임.

$ git revert (커밋아이디)

저장소 내 파일 삭제

📍 로컬 영역에서 제거

$ git rm (파일명)

📍 리모트 영역에서 제거

$ git rm (파일명) --cached
$ git rm -r (폴더) --cached

✎ --cached는 리모트로 이미 push까지 했을 경우 붙이는 옵션
✎ 이후 commit하고 push 다시 해주면 remote에 반영됨

📍 처음부터 특정 파일 커밋 안 하기

.gitignore파일을 생성해 git에 추가하고 싶지 않은 파일이나 폴더 리스트를 입력

✎ .gitignore 파일 목록 검색

$ git ls-files -o -i --exclude-standard

-o : untracked files
-m : modified files
-d : deleted files
-c : cached files
-i : ignored files
--exclude-standard : .gitignore

저장소에서 코드 가져오기

📍 origin에서 코드 가져오기

$ git pull origin master

📍 원격 저장소에서 코드 가져오기

$ git clone (url) (저장할 폴더 이름)

📍 원격에서 로컬로 코드 가져오기

$ git fetch origin

📍 병합하기

master 브랜치 또는 원하는 브랜치로 이동 후 병합하고자 하는 브랜치를 병합

$ git checkout master
$ git merge (브랜치명)

📍 특정 브랜치를 다른 브랜치의 코드로 대체

$ git checkout (바뀔 브랜치)
$ git reset --hard (타깃 브랜치)

출처 : https://velog.io/@augus-xury/github-%EC%82%AC%EC%9A%A9%EB%B2%95-%EA%B0%84%EB%8B%A8-%EC%A0%95%EB%A6%AC

position 속성 정리

1.프로필 모양에서 세팅 클릭

2.Edior Preferences 클릭

3. 스크롤 쭉 내려서 Editor Options에서 설정하고픈 옵션들 선택

자동완성,자동저장등이 있다

그 외에도 여러가지 설정이 가능한데 스페이스 누르면 2칸 띄우기 ,화면 테마 바꾸기 등등이 있다

<!-- ul : 목록 -->
<!-- li : 항목 -->

<!-- ul의 역할 : li의 부모 -->
<ul>
  <!-- li의 역할 : 항목을 표현 -->
  <li>동물</li>
  <li>식물</li>
  <li>광물</li>
</ul>

<ul>
  <li>과일</li>
  <li>야채</li>
</ul>

<ul>
  <li>포유류</li>
  <li>조류</li>
</ul>

<ul>
  <li>금속</li>
  <li>비금속</li>
</ul>

리스트를 나열할 때 ul,li를 주로 쓴다

<!-- ol : 목록(순서있는 목록) -->
<!-- li : 항목 -->

<!-- ol의 역할 : li의 부모 -->
<ol>
  <!-- li의 역할 : 항목을 표현 -->
  <li>물을 끓인다.</li>
  <li>라면을 넣는다.</li>
  <li>후레이크와 스프를 넣는다.</li>
  <li>맛있게 먹는다.</li>
</ol>

<!-- ol : 목록(순서있는 목록) -->
<!-- li : 항목 -->

<!-- ol의 역할 : li의 부모 -->
<div>
  <!-- li의 역할 : 항목을 표현 -->
  <div>물을 끓인다.</div>
  <div>라면을 넣는다.</div>
  <div>후레이크와 스프를 넣는다.</div>
  <div>맛있게 먹는다.</div>
</div>

순서가 있는 목록 항목등이 있는 자료에는 ol ,li를 쓴다