66일차 수업정리(RestController, ajax)

**@RestController

    => Spring4.0 부터 제공하는 Controller

    => 요청 처리 메소드에서 String 리턴시 String을 그대로 클라이언트에게 전송

        - DTO 또는 Map 그리고 List나 배열을 리턴하면 JSON형식으로 변환하여 클라이언트에게 전송

    => String을 리턴하는 경우 csv를 제공하고자 하는 경우이고 그 이외 자료형은 JSON

**ajax(Asynchronous JAvascript Xml)

    => 비동기적으로 서버의 데이터를 가져와서 사용

    => 전체화면 갱신 없이 데이터를 가져와서 화면의 일부분을 수정하기 위해서 주로 사용

        - 모바일처럼 네트워크 안정성 담보 불가능 상황의 경우, 전체화면 갱신하는 도중 네트워크 해제시 화면 출력 불가

        - ajax를 이용하면 서버의 데이터를 가져와서 출력하는 부분은 나중에 보여지고 다른 부분은 계속 출력

        - 가져와야 하는 데이터가 많은 경우, 전체 화면갱신의 형태사용시 데이터를 전부 가져올때 까지 화면 출력 불가

    => 최근에는 SPA(하나의 페이지로 모든 콘텐츠를 제공 - Single Page Application)가 유행인데 ajax를 기반으로 생성

**Marshalling

    => RPC(Remote Procedure Call) : 원격에 있는 프로시저를 호출

    => 대표적인 RPC가 Web Server

**XML 출력

    => Marshalling View를 이용하여 XML 형식으로 가능

    => 아직도 RSS에서는 xml을 주로 이용

        (RSS - Rich Site Summary - 뉴스, 블로그처럼 실시간으로 변경되는 데이터를 제공하는 콘텐츠 표현방식)

    => 직접 서버를 만든다면 JSON을 이용하는 것이 효율적

    => XML Parsing은 반드시 해 두어야 함

    => Backend 개발자는 데이터를 생성하는 것과 파싱하는 것을 모두 할 수 있어야 함(CSV, XML, JSON)

    => Front End 개발자는 데이터 파싱을 할수 있어야 함

    => XML을 출력할 때는 DTO 클래스에 출력할 속성을 설정

        - DTO 클래스의 List를 갖는 별도의 클래스를 생성하여 데이터를 저장 Marshalling View로 

**Error

1. 물리적 에러 : 문법 오류로 인해서 애플리케이션이 실행이 안되는 것

    => 대다수의 IDE는 문법오류 발생시 오류에러 표시를 출력

    => 컴파일을 하고 실행되는 언어들은 IDE가 코드를 작성하면 그때 컴파일을 해보고 오류표시를 해줌

        - 소스파일 작성후 ClassNotFoundException 발생시 IDE가 컴파일을 못한 것이므로 클래스를 지우고 다시 생성

    => 컴파일 없이 한줄씩 읽으며 실행하는 스크립트 언어들은 IDE에서 에러 표시를 하지 않음

    => 이 경우 소스코드를 읽어가면서 에러나는 부분을 직접 수정

 

2. 논리적 에러 : 문법상의 오류는 없어 실행은 되지만 결과가 예상과 다르게 나오는 것

    => 로직을 잘못 설계하여 발생하는 에러이므로 디버깅(메모리의 값들을 확인)하여 잘못된 로직을 수정

 

3. 예외(Exception) : 문법상의 오류가 없어 실행되지만 특수한 상황이 발생하면 프로그램이 중단되는 것

    => 예외 메시지를 읽고 수정해야 함

    => 소스코드에서 이런 문제 발생시 예외처리하여 예외가 발생시에도 계속 수행하도록할지 결정

        - 이런 예외는 별도의 파일에 기록 해두는 것이 좋음

        - 개발자가 해결가능 예외, 불가능 예외가 있는데 불가능 예외의 경우 다른 방법으로 해결해야 하므로 기록이 필요

//if문처럼 동작 - catch는 여러개 생성 가능
try{
	예외가 발생할 가능성이 있는 코드
}catch(예외변수){
	예외가 발생했을 때 수행할 내용
}finally{
	예외여부에 상관없이 수행할 내용
}

 

4. 단언(Assertion) : 특수한 상황이 발생하면 강제로 예외를 발생시켜 애플리케이션을 중지시키는 것

    => 조건을 만족하는 경우에만 애플리케이션이 수행되도록 하는 것

**Web에서의 예외 처리

    => Web Page에서는 예외 발생시 WAS가 가지고 있는 예외 페이지가 출력되도록 되어있음

    => 되도록이면 예외 발생시 별도의 페이지를 출력해주는 것이 좋음

**Server에서의 예외 처리

    => 데이터를 넘겨주는 서버 구축시, 예외발생, 잘못된 파라미터 대입시 해당하는 데이터를 만들어 주는 것이 좋음

**Web Programming에서의 예외 페이지를 출력

1. jsp 페이지나 web.xml 파일에 예외가 발생하면 보여질 페이지를 설정

 

2. Controller에서 예외가 발생했을 때 사용할 페이지를 직접 설정

    => @ExceptionHandler 어노테이션을 이용

**Error 페이지 작성

    => jsp 파일에서는 isErrorPage 속성을 true로 설정하면 exception 객체를 사용할 수 있는 페이지가 됨

    => IE 하위버전에서는 에러페이지의 내용이 512바이트가 안되면 IE 자체 에러페이지를 출력

        - edge는 다른 브라우저와 동일하게 처리

**변경 가능성이 있는 문자열 작성

1. Java에서 작성된 경우 : 문자열 변경시 compile, build, run을 전부 다시 수행

2. 일반 텍스트 파일에 작성된 경우 : 문자열 변경시 run만 다시 수행

3. 데이터베이스에 저장해서 읽어서 출력하는 경우 : 아무것도 할 필요 없음 - 대신 읽어올때 느림

**지역화 코드

    => 언어코드_국가코드

        - ko_kr - 대한민국

        - en_us - 미국

    => 대다수의 API에서는 지역화를 할 때 기본 이름에 _언어코드나 국가코드를 설정

**유효성 검사 - Validation Check

1. 클라이언트 사이드

    => 웹의 경우는 서버에게 데이터를 전송하기 전에 파라미터의 유효성을 체크

    => 응답이 빠름, 서버의 트래픽을 줄일수 있음

    => 보안이 취약

    => 클라이언트 사이드의 코드는 유저가 확인 가능

    => 코드의 난독화를 이용해서 보안을 유지

        - 의미없는 주석을 추가하거나 공백이나 엔터를 제거해서 수행

    => 웹의 경우는 HTML5의 속성이나 자바 스크립트를 이용해서 수행

 

2. 서버 사이드

    => 클라이언트가 서버에게 데이터를 넘겨주는 시점에 수행

    => 보안이 필요한 데이터는 무조건 서버에서 유효성 검사를 수행

        - 데이터는 네트워크를 이용해서 전송시 변질의 위험이 있음

    => SQL의 매개변수로 사용되는 데이터는 반드시 데이터베이스 작업전에 유효성 검사를 해야함

    => 암호화를 하지 않은 상태에서 로그인처리

select email, pw 
from user 
where email = #{email} and pw = #{pw};

위의 경우 비밀번호를 ddd or 1=1 형태로 대입하면 결과가 true

    => 비밀번호는 복호화가 불가능한 암호화를 이용해서 저장, DB가 아니라 Service에서 비교하도록 만들어야 함

 

3. 데이터베이스

    => 제약조건을 이용해서 유효성을 검사

 

* 유효성검사는 속도가 좀 느려지더라도 여러번 수행하는 것이 좋음

* Spring에서의 유효성 검사는 서버에서 수행

**primary key나 unique 한 데이터의 중복 검사는 서버를 이용

    => 초창기에는 팝업창을 이용하여 이러한 작업을 수행

        - 그 이후에는 ajax를 이용하여 검사를 수행

        - 최근에는 데이터를 전송할 떄 서버에서 수행하는 형태로 변경

 

**Spring에서의 유효성 검사

    => Validator 인터페이스와 Erros 그리고 BindingResult 클래스를 이용하여 유효성 검사를 수행

1. Validator 인터페이스는 유효성 검사를 수행해주는 메소드를 소유한 인터페이스

    => 유효성 검사를 수행하고자 하는 경우 Validator 인터페이스를 상속받는 크랠스를 생성

  1) public boolean supports(Class <?> clazz)

    => 유효성 검사 수행 DTO 클래스.class.isAssignableFrom(clazz)를 호출하여 리턴

  2) public void validate(Object target, Errors errors)

    => 이 메소드에서 target을 DTO 클래스로 형변환하고 필요한 검사를 하고 errors에 에러메시지 설정

 

2. Member 클래스의 유효성 검사 클래스

public class MemberValidator implements Validator{
	public boolean supports(Class <?> clazz){
		return Member.class.isAssignableFrom(clazz);
	}

	public void validate(Object target, Errors errors){
	Member member = (Member)target;
	if(member.getEmail() == null){
		errors.rejectValue("email", "메시지이름");
	}
}

 

**Web site를 위한 서버, REST API 서버

    => Web site를 위한 서버 : 서버가 많은 일을 수행, spring 유효성 검사를 사용

    => REST API 서버 : 클라이언트가 많은 일을 수행, Spring 유효성 검사가 아닌 일반 로직으로 유효성 검사 수행