22-09-07_jsp(1)

 

어제 수업의 복습..

 

A a = new A();는 크게 3단계...

 

메모리 공간은 크게 두가지

G.C의 대상이 되는 공간 / 안 되는 공간 둘로 나눌 수 있음. 

 

1)non G.C 상수 메모리 공간에 먼저 A가 들어감 (class)

2)그다음 G.C공간에 new A()

3)그 다음 new A()의 주소를 a에 할당

 

 

 클래스에 어떤 객체 메서드등이 들어갈지 디자인되어야하는데

 - 그걸 결정하는 과정을 모델링...

 프로그래밍 한다는건 실세계를 전산화해서 application의 형태로 운영

 실 세계에서 프로그래밍의 대상이 되는 객체...

 독립적으로 동작하는 사물 하나하나를 객체라고 함

 그 객체가 가진 전형적인 특성.

 그런 전형적인, 반복되는 특성을 뽑아서 유형화 시키면, 그 유형이 클래스임. 

 

 그 클래스를 만들어 내는 과정이 modeling임

 

---

 근데 우리가 어제 한 reflection은 반대임

 - 유형이 없는 상태에서 객체, instance만 가지고 있음. 

 이 객체가 가진 특성을 거꾸로 찾아가는과정, 역 모델링이라고 함. == reflection

 

 - ibatis, log4j 등의 프레임워크는 reflection기술 기반으로 구성됨.... 수없이 많은 프레임워크, 라이브러리 등을 쓸텐데, reflection에 대한 이해가 기반되면, 이 기술들을 사용하는데 훨씬 편리해짐

 

--

 자바bean이라는 규약에 따라 만들어졌다는 전제 하에 reflection 함

 프레임웤들을 사용하기 위해... 이 규약대로 우리도 모델링해야 함,

 

marshalling... 두개 이상의 피어에서 사용되어야?

 

web : 두개 이상의 피어가 데이터를 주고받기 위해 존재하는 공간. 

 

데이터를 생산하는 생산자 : server

소비하는 자 : client

 

http라는걸 이용해서 1) c -> s 요청 보내면, 2) server에서 처리

 3) res 나가면 한개 사이클 돌아감

 

--

Line, header, body....

 

body에 들어가는 컨텐츠를 어떻게 서버로 보낼 것인가....

 

server에서는 content를 해석할 수 있어야 하는데 두 시스템이 서로 다른 구조를 기반, 서로 다른 언어를 기반한다고 하면 데이터 표현방식이 달라져서, 

첫 번째로필요하한게, 공통 메세지 방식 ==JSON, XML

 

(둘의 차이)

 - XML : 중량표현방식 / JSON : 경량표현방식

 - scheme : 제약조건등....(xml이 가짐)

-- 어느 하나가 더 나은방식이라고 할 수 없고, 장단점이 있음. 경우에따라 사용할 뿐

 

 

--

Client side에서 js

server side에서 java 쓴다고 하면 표현방식이 다른데

 

 data를 그대로 보내면 이해X, client side에서 data 보낼때 xml/json 형식으로 바꿈 ==marshalling

 받는 쪽에서 다시 native data로 운영해야 함. 원래의 데이터로 복원하는 과정 ==unmarshaliing

 

 ---------------

* 
 * native data   ->   JSON/XML   ->   byte array   ->   JSON/XML   ->    native data
 *       Marshalling          Serialization         Deserialization          UnMarshalling
 *
 *
 * native data   <-   JSON/XML   <-   byte array   <-   JSON/XML   <-    native data
 *       UnMarshalling          DeSerialization         serialization          Marshalling
 *

---------------------

 --> 일반적으로 두개 이상의 pier에서 데이터를 주고 받을때 이런 과정이 있어진 것. 

 

직렬화(serialization) : 0,1의 bite로 데이터를 바꾸는 것. 

 marshalling !=serialization

 

 marshalling 안에 seriallization이 포함된 것처럼 표현하기도 함. 

 사실은 두 단계의 작업이지만 묶어서 표현하기도 함. 

 

 --mar-- /unmar-- :만들어 낸 데이터를 내가 아닌 다른 시스템이 사용하도록 하는게 전제로 깔려있다. 

 

- xml, json 으로 marshalling하는 과정은 크게 차이가 없지만, data는 차이가 있어지게 되었었음....

 

-----------------------

오늘수업

 

https://aws.amazon.com/ko/what-is/restful-api/

RESTful API가 뭘까요(https://aws.amazon.com/ko/what-is/restful-api/)

marshalling이랑 같은?

 

위에 처리과정이랑 같져?

그러면 RESTful API라는거는 뭐냐...

 

어디서 많이 봤던 애들이 있음. 쟤네 둘 합치면 Line이고..

헤더....

 

그러면 뭐.. 하던거랑 비슷한데 차이는 뭐지

 

RESTful이라는게 붙는데 이거 어디서 봤더라

 

memberInsert.do

   --> 메서드가 의미가 없음. 이 url에는 뭘 하겠다는 행위가 적혀있음

member POST

  --> 이런 식으로 구성하면 행위가 없음. 이런 걸 restful url이라고 함,....

 ==> 이런 걸 restful요청이라고...한다고...

 

뭐지

특징이 두가진데..... 

1)?

2) xml과  json으로 뭐가 나온다고

 

 

 

페이지 소스를 보면 데이터보다 수식, 꾸며주는게 많음

RESTful API의 전제조건 

1) 두개 이상의 피어가 통신할떄 사용

2) ??

 3) 그에 대한 응답데이터가 나올 때 html이 아니라 수식어는 제외하고, 데이터만 있는 xml이나 json으로 나옴

 

이 세가지를 만족할 떄 RESTful service라고 함

 이 서비스 많이 써야 된대

 

 ==> 이걸 쓰려면 RESTful API 원리? 를 알아야 된대

 

========================

오늘 할거 세가지

 1. 응답데이터...패키징하는구조?

 2. 응답데이터 안에 포함될 데이터의 종류, 어떻게 사용할지.. 그리고 어제 한걸 약간 변형해서 또 본다고

 3. calander

 

ㅎㅎ?우리 진도가 4일이 늦대

40일 안에 끝내야 되는 내용들이래...

그걸 끝내야 일할수있대..

그에대해 부담이있으시대..

 

--

 1.응답

 

.

응답데이터도 보면 request랑 구조가 비슷하져

 

get메서드는... body가없어..

 

응답의 세가지 part

Line

header

body

실제 서비스하는 자원 자체가 들어가는건 body

 

 body에 들어가는..내용이 나중에 수식되거나 한다고하면 수신자는 client... 그러면 server는 client가 사용할수있도록 body를 구성해줘야 함. 

 

그러면 응답에서 가장 먼저 해야하는거는

1)뭐가필요한지... ..??

2)자원을 찾았으면 service를 해줘야하는데, 이 자원을 어떤 방식으로 표현해서 전송할지

 (request에서 뭐로 xml,html... 받을지...를 accept라는걸 통해서...표현...?... metadata도 가지고 놀아야된다고...)

 

경우에 따라서 body에는 xml, json...들어갈수있음..

그럼 서버에서 넘겨줄 때, xml만 포함할 게아니라. 내가 지금 보내는게 xml이야.이런 식으로 표현해서 보내줘야함. 그게 mytype인데 이게 header에 들어간다고 함.

 

실제 서비스 되는 컨텐츠가 body에 들어가고, 컨텐츠에 대한 부가정보(meta-datA)가 header에들어감. 

그러면 line에는? 뭐가들어가나용

 

클라이언트 입장에서 제일 궁금한건 성공/실패여부...아니면 다른 영역인지 뭐...=>숫자로 표현

 상태코드 : 200이면 성공. 

 

 성공했으면 이제 body의 데이터를 꺼내야 하고, 이걸 가지고 뭐해야되는지가 header에 의해 결정

 

 ** 편지를 보내고 받는 구조와 정확하게 일치한다고 함. 

 

- 근데 200만아니라.. 상태코드가 여러개임... 

 이 상태코드의 종류가 어떤 것들이 있고, 각각의 상태코드가 어떤 의미를 가지고 있는지, 뭘 표현할 수 있는지 그런 것들을 보는게, 우리가 해야 할 첫 번째 내용이라는거죠...

 

-- 자 이제 이클립스로 가자..

 

05 폴더랑 jsp파일을 만들었음.

05 폴더랑 jsp파일을 만들었음.

 이제 쓰는 내용들은 좀전에 설명한거 정리중임

##

 

//위에 주석으로 못 달은 것들 추가로 적어줌

 * Accept라는 header를 통해 알게 됨 ( xml인지 json인지 뭔지....)

 * chunk.. : browser에서 몇 %가 다운로드 되었는지 보여주려면, Content-length라는 메타데이터가 필요함

 몇개의 chunk가 전송되었는지 계산해서 보여주는거니깐....

*Status Code : 상태를 알려주는 세자리 코드...

 

 

status code : 요청이 정상으로 처리됨.

 

요건 요청header...

이건 이 식별(ㅁㄴㅇㄹ)에 대한 자원이 존재하지 않음. 404

예를들면 이런 식으로 개발자 실수인 상태에서 실행하면

 

500뜸

왜 500은 500만뜰까? 누군지도 모르는 client에게 서버측에 대해 자세히 알려주지 않겠다는 것. 

client측 오류는 자세히 알려줘야, 뭔지 알고 client가 다시 요청을 보낼 수 있음. 

 

BAD REQUEST == 400 : 필수 데이터 누락, 데이터 타입 부적절, 데이터 길이 부적절

401 == 인가되지 않음.

FORBIDDEN==403,

401, 403은 접근을 허용하지 않겠다 --> 보안 처리를 위한 접근 제어

예를들면, 401은 로그인 전에... 일반 입력요소에 주는 내용인데, 로그인하세요 처럼

403은, 로그인 했는데 관리자가 아니네? 너는 권한이 없음. 정도의 차이

 

METHOD_NOT_ALLOWED ==405

405. 보통 servlet을 만들고 전혀 override를 안하거나... 그러면 servlet이 405를 내보냄,.

메서드에 비해 너무 큰 요청이 오거나 하면....

 

NOT_ACCEPTABLE : request의 header와 연관있는 놈임

accept에서는 json을 줘야됨 뭐 예를들면

 

근데 내가 json을 줘야 되는데 서버에서 json을 내보낼 능력이 없어. 그러면 406내보냄. 

accept라는 요청헤더와 연관있음. (서버가 해당 응답 컨텐츠 타입을 처리할 수 없음)

 

 

415 ==&nbsp;서버가 요청에 포함된 컨텐츠를 처리할 수 없음.

서버가 예를들면 json unmarshall 해야 하는데 json unmarshaller가 없으면 그 편지를 읽을 수 없음. 그러면 이거 뜸. 

Content-Type이라는 header가 server로 왔는데 서버에서 이걸 감당할 수 없을때...

 

 

100번대는 없다가 나중에 생긴 catergory인데... 현재진행형임...

 아잇 설명 못들었네ㅠ

 얘는 일부만 사용됨.....(webSocket 을 이용한 실시간 양방향 처리) 이런거....

 

http가 가진 단점을 보완하려고 나온 websocket...

 내가 한번 연결을 수립해놓으면 의도적으로 끊기 전까지 연결을 유지함. 그래서 push message를 보낼 수 있음. 

 실시간 채팅 같은거에서 이용됨. 

 

WebRTC : whale..의 on이나 gogle의 meet이라는 서비스를 이용하면.. zoom없어도 음성, 영상 등이 실시간 양방향으로 통신이 됨.... 이 때 WebRTC  API 를 사용하고, 100번대 코드를 이용하게 됨...

 

우리도 시간남으면 100번대 상태코드를 이용해서 실시간 양방향 어쩌구를 해보자고..

 

 

300번대들은 애매한놈들임

실패는 400, 500, 성공은 200인데... 300은 성공도 실패도 아닌 어딘가의 뭣같은녀석들임

302, 307, 304가 주로 사용됨.

  - 301 / 302 / 307 (Moved) 
  - 304(Not Modified)

 

304는 Not Modified인데... 어떤 의미로 쓴다고 했는데...

 

 1) 요청발생 

 2) 두번째 요청 발생 (근데 이미 캐싱된 데이터가 있음)

 3) 서버에서 304가 나왔음 (안바뀜)

 4) 캐싱영역의 캐시데이터를 이용함

 

300번대는 클라이언트의 추가 액션이 필요함.

 

 - 뜯어봤더니 location header가 있으면... 그쪽방향으로 추가 액션을 하겠죠... 이게 뭔소리지

 

300~ : 클라이언트의 추가 액션이 필요함.
301 / 302 / 307 (Moved) - Location 헤더와 병행. Redirect 이동구조에서 활용
304(Not Modified)

 

 

 

이 세 가지 메서드를 통해서 status code를 변경할 수 있다.

 

1차로 마무리함....

<%@ page language="java" contentType="text/html; charset=EUC-KR"
    pageEncoding="EUC-KR"%>
<!DOCTYPE html>
<html>
<head>
<meta charset="EUC-KR">
<title>05/responseDesc.jsp</title>
</head>
<body>
<h4> response (HttpServletResponse)</h4>
<pre>
	:  서버가 클라이언트쪽으로 전송하는 컨텐츠에 대한 모든 정보를 가진 객체.
	
	Http의 response packaging
	1. Response Line : Status Code, Protocol/version
		Status Code : 요청 처리 성공 여부를 알려주는 상태코드
		100~ : ING... (webSocket 을 이용한 실시간 양방향 처리), WebRTC
		200~ : OK
		300~ : 클라이언트의 추가 액션이 필요함.
			301 / 302 / 307 (Moved) - Location 헤더와 병행. Redirect 이동구조에서 활용
			304(Not Modified)
		400~ : 클라이언트측 오류로 실패
			404(Not Found, Not Exist)
			405(Method Not Allowed)
			400 : 필수 데이터 누락, 데이터 타입 부적절, 데이터 길이 부적절...
			401(UnAuthorized)/403(Forbidden) : 보안 처리를 위한 접근 제어
			406(Not Acceptable, request Accept Header) : 서버가 해당 응답 컨텐츠 타입을 처리할 수 없음
			415(Unsupported Media Type, request COntent-Type Header) : 서버가 요청에 포함된 컨텐츠를 처리할 수 없음.
			<%
				response.setStatus(sc)
				response.sendError(sc)
				response.sendRedirect(location)
			%>
		500~ : 서버측 오류로 실패
			
		
	2. Response Header - Contents metadata
		Content Type(request Accept header pair) <!-- Accept라는 header를 통해 알게 됨 -->
		Content-Length <!-- 데이터 전송때 얼마나 되었는지 등을 보여줄 수 있어야해서 -->
		refresh(Reload)<!-- 현재 페이지를 새로고침해서, 새로운 페이지를 연결할 때 -->
						<!-- 이걸 이용해서 자동요청이라는걸 발생시킬 수 있음.  -->
		Cache-XXX <!-- 캐시 어쩌구.. 캐시와 연관된 것들임 -->
				<!-- 캐시를 남길지 말지, 제한시간은 어떻게 둘지 등... -->
				<!-- 브라우저가 캐시를 남길 때 어떤 정책에 의해서 남길지도 결정하고... -->
				
	3. Response Body(Content Body, Message Body )
	
</pre>
</body>
</html>