스프링 부트

3일 동안 스프링 부트 교육 들으며 작성한 코드 커밋 내용
꽤 열심히 한듯 나?
근데 커밋 메시지가 너무 근본 없다...

---

@RequestScope

• 특정 url 요청이 들어올때 쿠키를 생성,삭제해주는 Request 클래스가 있다고 하자.
• 쿠키 관리가 필요한 url 요청시 마다 Request 클래스 객체를 만들어주는 것은 비효율적이다.
• 그러면, Controller나 Service 등이 아닌 Request 클래스를 스프링 빈으로 등록하는게 좋을까??
• 이것도 스프링 빈으로 등록하면 메서드마다 일일이 객체를 생성할 필요없이 사용할 수 있다.
• @RequestScope 로 등록하면 요청이 발생할때마다 빈 객체가 생성되어 자동으로 주입된다.

---

세션

• 쿠키는 클라이언트가 정보 조작이 가능하므로 보안적으로 상당히 위험함.
• 보안을 강화하기 위해 사용하는 것이 세션임.
• 세션은 서버에서 관리하며, 클라이언트가 서버에 요청 시 세션에 클라이언트의 정보를 저장하고 클라이언트의 브라우저에는 세션id를 쿠키로 제공한다.
• 이때 제공되는 세션id는 JSESSIONID로 다른 사용자를 추적할 수 없는 암호화된 값이다.

세션 사용법

• request.getSession()
  • 현재 세션이 존재하면 기존 세션 반환, 없다면 세션 생성
• session.setAttribute(name, value)
  • 세션에 값 저장하기
• session.getAttribute(loginMemberId);
  • 세션에 해당 key 값으로 저장된 값 반환
• session.removeAttribute(name);
  • 세션에 해당 key 값으로 저장된 값 삭제
• session.invalidate();
  • 세션 전체 삭제

HttpSession session = request.getSession();
session.setAttribute(name, value);
session.getAttribute(name);
session.removeAttribute(name);

session.invalidate();

---

GET, POST

• HTTP 메서드 중 가장 일반적으로 사용되는 두 개의 전송방식
• 요청 방식
  • GET : URL 에 요청 파라미터를 담는 쿼리 스트링 방식으로 서버에 전송
  • POST : HTTP Request Body 에 파라미터를 담아 서버에 전송
• 요청 데이터 처리
  • GET : URL 에 요청 파라미터 정보가 보이므로 보안에 취약하다.
  • POST : URL 길이 제한이 없으므로 대량의 데이터 전송 가능, 요청 파라미터 정보가 URL에 노출 안됨.
• 캐싱
  • GET : 캐싱 가능, 동일한 요청에 대해서 서버에 요청하지 않고 캐싱된 데이터를 사용할 수 있다.
  • POST : 캐싱 불가능
• 안전성
  • GET : 요청 파라미터가 노출되므로 안전성 취약, 서버의 데이터를 변경하는 요청에는 적합하지 않다
  • POST : 요청 파라미터가 노출되지 않으므로, 서버의 데이터를 변경하는 요청에 적합하다.