레스트풀 : 프론트와 백을 완전히 분리하겠다. 해서 사용하는 거
자바용 라이브러리 : json(형태는 프론트가 있어야한다! 예쁘게 보여주기위해 )
자바에는 렌더링 엔지니어가 없기 때문에 html을 해석할 수 없다.
그래서 요즘에는
이렇게 안한다!
(2개의 구조를 배웠다)
mvc구조
json 응답하는 구조
jsp를 만드는 구조
jsp를 만들지 않는 구조 (화면구성은 어떤틀로 쓴다. (이름 못들음))
jsp구성요소
- html
- jsp 요소
자바 문법을 쓰려면 scriptlet을 싸용
expression 을 쓰는 것은
page directive 에는 buffer ... errerpafe같은 속성을 사용할 수 있다.
jsp의 요소중에서 directive 요소 말고 action tag 요소도 있는데 이걸 action 혹은 태그라고도 부른다 .
액션 태그중에는 standard태그로서 <jsp:include>가 있다.
위에 인클루드 두개가 다름. <차이점>
인클루드 디레티브 쓰면
jsp가 만들어질때 포함되는 것이고
jis.include는 실행시에 포함됨
<mvc>
소프트웨어 설계에서 세 가지 구성 요소인 모델(Model), 뷰(View), 컨트롤러(Controller)를 이용한 설계 방식.
.includ("a.jsp") jsp파일이 컴파일 되고 요청되면 드디어 include라는 메서드가 실행된다.
i변수가 미리 선언되어 있어야 되는데 없어서 컴파일 오류 > 즉 실행이 안된다.
선언도 안되어 있는 변수를 사용할 때에는 지시자를 사용
그게 아닌 경우는 태그를 사용한다.
우리가 사용한 jsp:
jsp는 요청을 받는 요청으로 사용하는 게 아니라 결과를 보여주는(화면의) 역할이다.
jsp는 자바 문법과 jsp전용 문법, html 태그들이 섞여 있기 때문에 > 유지보수가 어렵다.
>> jsp가 요청을 처리해 줄 컨트롤러 역할이 되는 것은 별로 좋은 방법이 아니다.
요청은 서블릿이 받고 응답은 jsp가 받는 구조가 좋다 !
(jsp가 요청을 받는 일까지 하지 말기! mvc 구조 사용하려면 완벽하게 분리하기!) # 모호하게 사용 x !!!
서블릿이 주로 제어의 역할을 하게 하자!
(forward "어디로 가~")
자바빈의 조건에 불충분하면 사용할 수 없기 때문에 USEBEAN 사용 X
getProperty : 값을 가져오는 용도로 쓰는데, 잘 사용안함
jsp에서는 Scripting element 를 잘 사용하지 않는다 (코드가 길어짐 > 유지보수 어려움)
될수있으면 scriptlet 과 expressin 사용을 지양해라
>> 대체 : expression language(EL) 로 사용!
EL
Expression Language 의 약어,
expression을 좀더 구체화한 언어가 EL이다.
EL의 내장되어 있는 객체
JSTL을 쓰기 위한 URI <c:set/>
사용자 정의를 쓰기 위해서도 prefix를 써줘여 됨
겉으로 보기에는 태그가 실행되는 것처럼 보이지만 class가 실행됨.
현재 jsp에서 쓰이는 요청용 객체에 httpservlet request / jspwriter 이 객체들을 greeting용 객체에서 사용 못함
그리팅용 객체에 있는 메서드 에서
pageContext를 얻어냅니다.
어떻게? jsp용 객체에서 greeting용 객체가 사용하려고 할 때 pageContext만 전달하는 것
리퀘스트 객체를 얻어낼 수 있다.
만약 요청전달 값이 id일때.
요청 ?id=id2
응답 id님환영
pageContext.setAttribute("이름", 값, (범 생략)) > 지금 사용중인 pagecontext에 추가하는 것
pageContext.setAttribute("이름", 값, 범위) >
>> 정리
jsp는 jsp용 스크립트, 디렉티브, 액션태그 요소 등이 있다.
공부를 하고보니까 script 요소가 너무 지저분 (코드 길어서 유지보수 어려움)
> el 표기법, jstl문법으로 바꿈
el이나 jstl을 사용해야 하는데
jstl을 사용하기 위해서는 taglib가 필요하다
포함하려면 inclulde 지시자나 include 태그를 써야 한다.
jsp 포워드, 유즈빈, 셋겟 잘 안쓴다!
pageContext : 지금사용하고있는jstl의 정보를 담고 있다. 매번 새로 만들어진다.
applicaion
Session Tracking
해야하는 이유?
http 프로토콜은 요청과 응답 연결끊김으로 구성되어 있다.
요청 > 응답 > 연결끊김
로그인 성공 후,
조회된 상품의 이미지/ 명(아메리카노) ./가격(1000원)
아래 장바구니에 넣기 버튼 있음
장바구니넣기 버튼 누르면 > 요청
백(서블릿)이 실행시킴
로그인 성공 과 장바구니 넣기 서블릿 다름
장바구니 요청 > 서블릿 > 응답
결제하기 버튼
결제하기 서블릿
(로그인된 사용자만, 장바구니에 내용이 있을 때 결제를 해준다)
결제를 요청하게 되면 로그인 된 사용자인지 아닌지 먼저 구별한다
로그인 성공한 사용자인 경우 와 로그인 안한 사용자인 경우로 나눠진다
로그인 성공 - 요청응답 - 연결끊김
상품조회 장바구니넣기 - 요청/응답 - 연결끊김
결제 - 요청/응답 - 연결끊김
id로그인성공 후 연결이 끊기기 때문에 결제때 로그인성공/실패 사용자 구분 어려움.
만약에 이게 연결이 계속 유지되는 경우에는 ? (연결이 안 끊김) 로그인 성공/실패 사용자 구분을 할 수 있다.
로그인 성공한 거를 크라이언트 사이트에 저장한다.
그리고 서버를 요청할 때마다 보낸다.
> 이렇게 하면 결제 시 로그인 성공된 사용자인지 아닌지 판단할 수 있다.
만약 위와 같은 경우에서 로그인 실패한 사용자의 경우에는 클라이언트에 로그인성공 응답을 안하고
클라이언트 입장에서 결제요청을 했을 때, 로그인성공한사용자인경우야 라고 전달 안하고 그 반대로 하기 때문에 결제요청안됨!
http = 요청/응답/연결끊김 이기 때문에
클라이언트 자료를 저장하고 요청할 때마다 서버로 보내준다.
sessionTracking
: 상태정보유지기술
-쿠키 : 클라이언트쪽정보유지기술
-세션 : 서버사이드쪽정보유지기술
쿠키의 경우 클라이언트에게 응답할 때 쿠키를 만들어서 응답을 해준다.
응답된 쿠키는 다시 클라이언트에서 서버로 요청할 때마다 그 서버에 자동으로 전달된다.
( 쿠키는 한 번 응답되면 해당 서버에 요청할 때마다 요청헤더로 서버에 전달이 되는 구성이다. = 자동전송)
쿠키가 많으면 많을수록 요청시에 헤더로 전송될 것들이 많아짐 > 요청이 더뎌진다.
(쿠키를 삭제하면 다음 요청시에 헤더로 따라갈 쿠키가 없기 때문에 요청이 빨라진다)
>>클라이언트 사이트 쪽에 정보를 유지시키는 것을 쿠키라고 한다.
쿠키는 웹브라우저쪽에 저장되기때문에 보안상 취약하다.
(예) 은행컴퓨터에서 첫번째 고객이 로그인을 해서 은행 웹브라우저에 그 정보가 저장되었을 경우,
두번째 고객이 와서 은행업무를 보려고 할 때, 첫번째 고객의 로그인성공정보가 요청헤더로 두번재고객이 요청했음에도 그 정보가 요청헤더로 실려간다. >> 보안이 취약하다.
위험한 자료는 쿠키로 만들지 않는다. (위험한 자료 예시: 계좌 비밀번호, 카드번호, 주민등록번호)
쿠키는 보안상 신경 안써도 되는 정보들만 만드는 것을 권장한다.
쿠키의 특징
쿠키는 이름과 값으로 저장이 되는데 255개(?) 문자까지만 저장이 가능하기 때문에 (특수문자도 안됨) 단순한 내용
쿠키의 값은 문자열로만 저장할 수 있다.
쿠키를 이용한 형식
(예) 오늘 하루동안 열지 않음 팝업창
세션
세션은 서버사이드에 저장하는 것, 값의 유형이 문자열뿐만아니라 다양한 자료형을 저장할 수 있는 object 타입!
(쿠키는 문자열만, 255개의 문자만 / 세션은 object타입 즉, 객체 타입을 저장된다)
클라이언트에 저장된쿠키가 서버에 요청이 될때마다 요청헤더에 실려간다.
쿠키가 많으면 많을수록 서버에 전송되는 쿠키가 많아지고, 요청 시간이 오래걸린다.
Session Storage탭 단위로 관리
local Storage 웹브라우저 닫혀도 계속 쓸 수 있음 (Header에 실려가지 않음. cookie와 차이점)
아이디 저장 (체크박스)
아이디가 저장될 자료는 local storage로 저장한다.
쿠키는 클라이언트 사이드에 저장되는 상태정보유지기술이다.
클라이언트사이드에 기억되기 위해 저장했는데 요청할 때마다 (자기 페이지 외에도 다른 페이지 요청에도) 헤더에 실려서 서버쪽 으로 흘러간다.
근데 굳이 그럴 필요가 없고, 근데 저장할 필요는 있는 애들은 local storage에 저장한다.
httpsession
은 인터페이스 이기 때문에 new키워드로 객체생성 할 수 없고.
request.getSession(); 으로 객체를 얻어와야 한다.
setAttribute로 추가한다.
서버사이드쪽에 세쎤이라는 객체가 하나 있고, setAttribute로 이름줌
request.getSession()
요청한 클라이언트 전용 http객체가 있는지 확인하고, 없으면 새로 만든다
요청헤더에서 JSESSIONID라는 쿠키가 있는지 존재를 확인한다.
쿠키가 없을 경우, 쿠키를 하나 만든다.
쿠키생성 (이름:JSESSOINID 값:(중복되지 않는 값. 예를들어 AAA가 중복이 안될 경우 AAA값으로 쿠키 만들기)"AAA")
응답헤더에 추가
쿠키를 만들어 놓은 다음에 JSESSIONID 쿠키값(AAA)에 해당하는 객체를 찾아낸다.
이 객체가 없으면 HTTPSESSION객체생성
객체가 있으면 반환함 (getsession())
최종 HTTPSESSION 객체를 반환하는 메서드가 getsession이라는 메서드이다.
쿠키가 만들어지지 못하는 상태가 되면 쿠키를 대신해서 urlrewrite라는 것으로 대체한다.
(1차 쿠키 활용> 활용 못할 때 urlwrite사용) (우리가 하는게 아니라 http객체?? 그 톰캣이 함 그일)
지금까지 공부한게 sessiontracking입니다요~~
http Session객체이 메모리에서 언제 없어지는가?
최종사용시간이 매번 셋팅(기록)이 되는데 이후 30분간 사용하지 않으면 자동 소멸이 된다.
'JAVA 수업 > 웹(WEB) 수업 기록' 카테고리의 다른 글
| 0717 수업내용 (2) | 2023.07.17 |
|---|---|
| 0711 수업내용 (0) | 2023.07.11 |
| 0710 수업 내용 (0) | 2023.07.10 |
| 0707 수업내용 (0) | 2023.07.10 |
| 0706 수업내용 (0) | 2023.07.07 |
