IT's 잡탕찌개 블로그

인터넷은 어떻게 동작하는가?
두개의 컴퓨터 사이에서 통신이 필요한 경우 우리는ㄴ 다른 컴퓨터와 물리적, 혹은 무선으로 연결되어야 한다.
이런 네트워크 연결은 단순히 두대의 컴퓨터로 제한되진 않는데 연결 수가 많아질수록 매우 복잡해진다.
(네트워크 연결 구조에 대해서는 나중에 포스팅 할 예정이다.)
이러한 복잡한 연결을 줄이기 위해서 각 PC는 "라우터"라는 장비에 연결되며, 이 라우터는 신호에 따라서 특정 PC에 메세지를 보내고 잘 도착하는지를 확인한다.
이러한 방식으로 특정  라우터에 소속된 pc 집단에서의 통신 또는 다른 라우터에 속한 pc집단 사이에 통신을 할 시 두대의 라우터 사이의 연결만으로도 통신이 가능해진다.

이러한 방식으로 네트워크를 확대하는 것이 가능하며 같은 네트워크에 속한 pc같의 통신이 가능해진다.
여기서 더 나아가 라우터로 직접 연결되지 않은 다른 네트워크에 "모뎀"을 통해  접근하며 다른 지역의 네트워크까지 통신이 가능해진다.
이러한 서비스를 제공하는 인터넷 서비스 제공 업체를 우리는 ISP(Internet Service provider)라고 부른다.

IP Address란?
그렇다면 네트워크 상에서 다른 PC에 대해서 어떠한 방식으로 특정을 하는 방법이 필요하다.
현재 우리의 인터넷 환경은 IP주소를 통해 특정 라우터 혹은 PC를 구분하는 방식을 사용한다.
IP주소 할당 방식 등 좀더 깊은 내용이 있지만 해당 포스팅에서는 다루지 않는다.

DNS
하지만 오늘날 우리는 naver등에 접속할 때 위의 IP 주소를 직접 URL창에 입력하지 않는다.
우리가 입력하는 것은 "domain"인데 이는 Domain Name Service를 통해 IP 주소와 mapping 되어 있기 때문에 어떠한 네트워크에 접속할지를 판단할 수 있다.
(DNS 역시 별도 포스팅을 통해 알아보자.)



참고 : https://developer.mozilla.org/ko/docs/Learn/Common_questions/Web_mechanics/How_does_the_Internet_work

restful api란 무엇인가?
restful api란 두 컴퓨터 사이의 정보를 안전하게 교환하기 위해 사용되는 인터페이스 중 하나이다.
여러 API 방식 중 일반적으로 REST 원칙을 따르는 API를 지칭한다.

대부분의 사람들이 REST API는 URL 을 통해서 Resource를 식별하고 Http Method를 사용하여 해당 Resource에 대한 행위를 규정하며 그 결과를 전달 받는 것으로 알고있다
이 포스팅에서는 REST API에 대해서 좀더 자세히 알아본다.

REST란? ( Representational State Transfer )
분산 하이퍼 미디어 시스템을 위한 API 아키텍쳐 스타일을 의미한다.
오늘날 HTTP 규약만 잘 지켜도 REST API 조건 중 다수를 만족할 수 있다.
그렇다면 REST API 아키텍처 스타일에는 어떤것들이 있을까?
주요 스타일은 아래의 6가지가 존재하며 해당 사항에 대해 좀더 자세히 알아볼 것이다.
. client - server
. stateless
. cache
. uniform interface
. layered system
. code on demand(Optional)

Client - Server
. UI는 client에서, data는 server에서 처리하여 관리한다.
. 즉, client와 server가 별도로 개선될 수 있어야 한다.

Stateless
. client와 server는 요청을 완료할 때 필요한 모든 정보를 제공해야 한다.
. 요청이 일어난 시점에 제공된 정보만을 사용하여 작업을 완료할 수 있어야 함.

Cache
. 응답은 cache될 수 있어야 하며, 이는 성능향상에 도움이 된다.

Layered System
. 계층화된 구조를 활용하여 각 Component의 행동을 제약하고 추상화 할 수 있어야 한다.
-> REST Server는 다중 계층으로 구성될 수 있고 보안, 로드 밸런싱, 암호화 계층 등 을 추가할 수 있다.


Uniform Interface
: resource에 대한 조작을 통일되고 한정적인 interface로 수행하는 아키텍처를 의미한다.
. resource는 uri로 식별이 되어야 한다.
. resource에 대한 관리는 http method에 해당 방식이 포함되어야 한다.
-> http method로 CRUD 구분
. self-descriptive message
-> message는 스스로를 설명해야한다
-> message 안에 해당 요청, 응답에 대한 모든 정보가 포함되어야 한다.
  => ex : message 안에 Content-Type이 생략되어 있는 등의 경우는 self-descriptive message를 불만족.
. HATEOAS
-> application의 상태는 항상 hyperlink를 이용해서 전이되어야 한다.
  => ex : 게시글 생성 버튼 링크를 통해 application의 상태가 변경된다.

Code on Demand(Optional)
. Server에서 보낸 정보를 토대로 client에서 code를 실행할 수 있어야 한다.
-> ex : server 가 client 에 응답으로 보낸 것중 javascript

Uniform Interface가 필요한 이유
. server와 client 간의 독립성을 보장하기 위해서
-> ex : server가 기능을 변경해도 client는 업데이트 할 필요가 없다.
-> ex : web의 경우 브라우저 업데이트가 되어도 web site는 변경할 필요가 없다.

REST API를 구현 시 주의해야 할 설계 원칙은 어떤 것들이 있을까
. Url 은 Resource를 표현해야 한다.
. Resource에 대한 행위는 Http Method를 통해 나타낸다.
. 슬래시는 Url 마지막에 사용하지 않는다.
. 하이픈은 Url 가독성을 높이기 위해서 사용할 수 있다.
. 언더바는 띄어쓰기처럼 보일때가 있고, Url에 혼동을 줄 수 있어 사용하지 않는다.
-> 하이픈을 사용하는걸 추천
. Url 경로에는 소문자만 사용한다.
-> Url은 대소문자를 구분하기 때문에 다른 resource로 인식할 여지가 있다.
. file 확장자는 url에 포함시키지 않는다.
-> 대신 Header에 AcceptHeader를 사용하여 file의 확장자를 알수 있게 한다.


REST API를 통한 CRUD 작업과 이에 대응하는 Http Method
. CREATE : POST
. READ : GET
. UPDATE : PUT, PATCH
. DELETE : DELETE
=> Http method와 관련된 CRUD에 대해서는 추후 좀 더 자세한 포스팅으로 다룰 예정이다.


참고
. https://youtu.be/RP_f5dMoHFc?si=q-5csLAZvzXnm_-h

. https://kmkunk.tistory.com/m/139

Spring ApplicationContext란 무엇인가?
Spring에서 IOC Container를 BeanFactory라고 하며 이 BeanFactory에 여러 기능이 추가된 class를 ApplicationContext라고 한다.

Bean Factory는 SpringContainer의 최상위 interface로 spring bean 을 관리 및 조회하는 역할을 한다.
BeanFactory를 기반으로 ApplicationContext에 추가된 부가기능으로는 환경변수 관련 처리, Application의 event를 발생시킬 수 있으며, 다양한 리소스를 읽는 등 여러 기능이 존재한다.

Application Context가 bean요청을 처리하는 과정
0. application context는 @configuration 이 붙은 class는 설정파일 정보로, @Bean, @Component가 붙은 method는 method 이름으로 bean 목록을 작성한다.
1. client가 특정 bean을 요청한다.
2. application context는 현재 등록된 bean 목록에서 해당 이름의 bean이 존재하는지 확인한다.
3. application context는 설정 class로부터 bean 생성 요청 및 생성된 bean객체를 반환한다.

Application Context를 사용하여 SpringFramework가  얻는 장점
. @Configure Annotation을 통해 설정과 관련된 class를 구분, 관리할 수 있다.
. 설정 class를 구분함으로써 client는 구체적인 설정 class를 알 필요가 적어진다.
. Application Context를 통해서 전반적인 IOC 서비스를 제공할 수 있다.
. Application Contextㄹ르 통해서 다양한 Bean을 검색할 수 있다.

Spring ApplicationContext에 등록된 Bean
Application Context에 등록된 Bean의 경우 기본적으로 Singleton으로 관리된다.
Spring에서 여러 Bean을 요청할 시 모든 요청에 대해 활용되는 객체는 단일 객체이며,
이로 인해 여러번 요청이 오더라도 매 요청마다 새로운 Bean 객체를 생성하지 않고 단일 객체를 활용한다.
(MultiThread에서 해당 Bean을 공유한다고 한다.)

Java를 통해 직접 Singleton객체를 만들 때 단점은 아래와 같다.
. private 생성자를 지녀 상속이 불가능하다.
. server 환경에서는 singleton이 1개만 생성됨을 완벽히 보장하지 못한다.
. static 상태를 만들 수 있기때문에 객체지향적이지 못하다.

이에 반해서 Spring 이 직접 Singleton 객체를 만들고 관리하는데, 이를 Singleton Registry라고 부른다.
Singleton Registry의 장점은 아래와 같다.
. static method나 private 생성자 등을 사용하지 않아 좀더 객체지향적 개발이 가능하다.
. test를 하기에 편하다.

다만 Bean 객체 정의 시 주의할점이 존재한다
. Bean 객체가 singleton으로 관리되기 때문에 각 객체는 내부에 상태정보를 지니면 안된다.
-> stateless 를 유지해야 함.
-> multi thread 환경에서 특정 상태를 지니면 위험소지가 존재.


참고 포스트
. https://mangkyu.tistory.com/151

spring에서의 IOC를 사용하는 이유는 어떤 것이 있을까?
객체지향 원칙을 준수하며 객체관리를 framework에 위임하고 개발자가 구현하려는 부분으로
각각의 역할을 분리해 응집도를 높이고 결합도를 낮추어 변경에 유연한 구조를 유지할 수 있기 때문이다.
즉, 추상 class와 구현 class를 만든 뒤 추상 class를 주입 받도록 하여 개발자는 비즈니스 로직에만 집중할 수 있게 된다.

spring에서의 IOC 원리
특정 instance 가 필요할 때 IOC container에서 Bean으로 등록된 class를 확인하여 instance를 생성한다.
그 후 해당 instance 가 필요한 다른 Bean 객체에서 요청 시에 이를 자동으로 주입해준다.

spring에서의 DI 방식은 아래의 3가지 방식이 존재하며 이에 대한 자세한 포스팅은 추후에 다루기로 한다.
. 생성자 주입
. setter 주입
. field 주입

spring의 IOC container
spring에서 IOC를 수행하는 component를 Ioc container 혹은 spring container라고 부른다.
spring container는 객체를 생성, 객체간의 관계를 연관, 객체의 생명주기를 담당한다.
즉, spring container는 의존성을 주입하고 각 객체들끼리 연관지어 Spring application 을 동작할 수 있게 해준다.

spring bean란
spring bean 이란 개념은 Ioc container가 관리하는 오브젝트들을 의미한다.

Spring ApllicatioContext
Spring 에서 ioc container의 역할을 담당하는 bean factory에 여러 기능이 추가된 것 이다.
@Component Annotation을 사용하면 해당 class를 component scan을 통해서 Bean으로 등록해준다.
Spring ApplicationContext에 대해서는 추후에 더 자세하게 다룰 예정이다.

spring 을 공부하면 필연적으로 듣게 되는 단어가 있다

바로 IOC 이다.
IOC는 Inverse of control 이라는 의미로 "제어의 역전"이라는 의미이다.
IOC는 코드의 제어가 유저에게 있는것이 아닌 framework 등 제 3자에게 위임되는 것을 의미한다.
쉽게 예를 들어보자.

class A
{
 public void callMe()
 {
  ....
 }
}

현재 사용하는 framework가 A라는 class의 함수를 내부에서 호출한다고 가정해보자.
즉, 해당 class에 대해서 함수의 호출 혹은 객체 생성등을 framework가 제어하고 있는 상태이다.
이러한 상황에서 우리가 A에 대한 callMe함수 오버라이딩 등을 통해서 정의한다면 해당 코드에 대해서는 framework가 직접 제어하는 상황이 되는 것이다. (DI에 대해서는 추후에 다룰 예정)

IOC의 실제 사용 예는 대표적으로 아래의 예가 존재한다
. Template Method
. DI ( Dependency Injection )
. Strategy Pattern
. Factory Pattern
. Service Locator

DI (Dependency Injection )
DI란 의존성을 주입하는것을 의미한다.
Ioc를 구현하기 위해 사용되는 대표적인 design pattern 중 하나로 특정 객체의 의존 관계를 객체의 외부에서 주입시키는 패턴이다.
전통적인 구현방식에서는 특정 A class에 대한 정의 후 A를 호출하는 식으로 프로그램이 구현된다.
하지만 DI의 경우, 우리가 A를 재정의한 A`를 정의하면 A에 대한 호출은 이미 외부에서 선언이 되어 있는 상태이기 때문에 A`의 code 가 호출된다.

DI는 어떤 조건을 지켜야 만족하는 것인가?
. class code 혹은 class model에서는 의존 관계가 노출되지 않는다.
. runtime 시점의 의존관계는 factory 등의 제 3의 존재가 결정한다.
. 의존관계는 object에 대한 레퍼런스를 외부에서 주입함으로써 만들어진다.

public class A
{
  prviate B b;
  
  public A()
  {
    b = new B();
  }
}

public class C
{
  private D d;
  public C(D d)
  {
    this.d = d;
  }
}

위의 코드 중 A에 대한 내용을 살펴보자.
A의 내부에선 B에 대한 객체 생성을 진행하며 이를 내부 변수로 지닌다.
이 과정은 DI라고 볼수 없는데 우선 B의 생성자가 A에서 호출되기 때문에 추후에 B의 생성자가 변경될 시 A가 영향을 받는 문제가 존재한다.
또한 위의 code를 보면 A는 B를 생성한다는 점에서 사실상 B와 A가 class 수준으로 관계가 생긴것으로 볼 수 있다. 이 점에선 위의 DI가 지켜야할 조건중 하나를 지키지 못한것으로 볼 수 있다.
반면, D와 C의 경우를 살펴보면 C는 외부에서 D에 대한 객체를 전달 받는 것을 볼 수 있다.
이렇게 객체를 전달 받으면 C는 D의 레퍼런스를 전달 받는다.
D와 C는 객체에 대한 의존을 갖고 class 수준의 관계는 맺지 않으며, 의존관계는 외부에서 주입당하여 만들어진다. 또한 runtime 시에 외부에서 의존관계를 지정하기때문에 DI에 필요한 조건들을 만족한다.

위의 예에서는 생성자를 통해 D를 전달 받기는 했지만 의존성은 setter 함수 혹은 interface 구현을 통해서도 삽입 될 수 있다.

public class SetterA
{
  private B b;
  ....
  public void setB(B b)
  {
    this.b = b;
  }
}

public class InterA extends injectorB
{
  private B b;
  @Override
  public void injection(B b)
  {
    this.b = b;
  }
  ...
}

interface injectorB
{
  void injection(B b);
}

이렇게 setter와 interface를 사용하여 의존성을 주입할 수 있지만 setter의 경우 함수 정의를 누락할 여지가 있다.

SpringBoot 에서 작업을 하다보면 Bean과 Component 라는 Annotation을 자주 볼 것이다.
위의 두 Anootation이 어떠한 역할을 하는지, 어느점이 다른지에 대해서 알아보자.

우선 IOC라는 개념이 있다
Inherited Oriented Class의 약자이다( 뻥이고 사실 Inversion Of Control의 약자이다.)
간단하게 말하자면 일종의 제어관계의 역전 이라는 의미인데 기존의 우리가 프로그래밍을 할 시
어떠한 class를 설계하고 해당 class를 code에서 직접 호출하고 관련 함수를 활용하여 output을 얻는다.
이러한 개념과 반대로 IOC는 지정된 방식을 사용하여 코드를 작성하면 code의 호출과 제어를 framework가 자동으로 진행하는데 이러한 특징 때문에 Inversion of control 이라고 부른다.
우리가 알아볼 Bean, Component, 그외 다른 Annotation 은 해당 class, method가 어떠한 역할을 하는지에 대한 meta정보 라고 생각하면 된다.

Bean Annotation
. Bean Annotation의 경우 서드파티나 사용자가 정의하지 않은 객체에 대해서 IOC에 등록(?)하고자 할 때 사용된다.
. 간단한 예 : User 객체를 반환받는 함수 정의

......

@Bean
public User getUser()
{
 ....
  return User.builder()
      .name("test")
      .build()
  ;
}

위의 code block을 보면 User객체를 사용자가 가공한 후 반환하는 것을 볼 수 있는데 해당 User객체는 springboot에서 기본적으로 제공하는 User class이다.
위처럼 User 객체를 가공 후 넘겨주는 code를 작성한 후 Bean을 지정하면, IOC에 의해서 User 를 사용하는 내부 구현에서 위의 함수를 호출하여 User 객체를 활용하게 된다.
=> 즉, 개발자가 직접 User객체를 사용하는 상위 함수를 구현하지 않아도 User를 쓰는 부분에선 해당 함수를 통해서 알아서 사용한다는 의미.

Component Annotation
. Component Annotation의 경우 Bean과 달리, 사용자가 직접 정의한 class에 대해서 IOC를 적용하기 위한 Annotation 이다.
. 대표적인 Component Annotation 으로는 Controller, Service, Repository 등이 있다.
-> 해당 Annotation 들 내부에 Component가 정의되어 있음.

우선 각 용어별로 간단하게 알아보자
우리가 많이 사용하는, 또는 많이 사용하게 될 Springboot는 Spring, SpringMVC와 많이 볼 수 있다.

인터넷에서 찾아본 각각의 대한 설명을 한번 살펴 보자.

Spring 이란?
. java 기반의 web app을 개발을 위한 오픈 소스 framework 이다.

SpringMVC 란?
. web app 개발에 있어서 MVC 패턴을 적용할 수 있게 spring에서 제공하는 framework 이다.

SpringBoot 란?
. web app 개발 시 필요한 설정 방식, 구현 방식등을 자동화, 제공하는 spring 기반의 framework이다.

위의 각 설명을 보면 spring, springMVC, springboot가 사실 구분이 필요한 것들이라는 것을 알 수 있다.

springboot와 springMVC의 공통점
. 둘다 모두 spring 기반의 framework이다.
. 구현방식에 있어서 사실 springboot가 초기 의존성에 spring-web을 포함하므로 사실상 MVC 구조로 구현된다고 볼 수 있다.
-> spring-web에 springMVC가 포함되어 있음.

springboot 와 springMVC의 차이점
. springboot는 기본 설정등이 자동화가 되어 있어 개발자가 불필요한 설정 작업을 하지 않도록 도와준다.
. 반면, springMVC의 경우 Dispatcher Servlet, HandlerMapping 등의 xml 파일에 직접 설정을 해야 한다.
. servlet 기반의 app을 싱행시에는 WAS가 필요한데 springMVC의 경우는 포함되어 있지 않지만, Springboot의 경우 기본적으로 Tomcat이 포함되어 있어 추가적인 설치가 필요하지 않다.


그렇다면 SpringBoot를 안 써본 사람은 굳이 springBoot를 써야하는 이유가 있을까?
현재 나처럼 SpringBoot를 배우는 입장으로써, 그리고 인터넷에서 알아본 사항들에 있어서 어떠한 장점으 있는지 아래 내용을 보자.

우선 SpringBoot는 의존성에 대한 부분을 알아서 관리, 권장해준다.
spring의 경우 xml 파일에 dependence에 대한 사양 정보를 각 버전까지 일일히 명시하고 관리해야 하지만,
SpringBoot의 경우는 단순히 어떠한 모듈을 사용할지 명시만 하면 의존성 주입이 완료된다.
-> 아직 spring과 springboot로 장기적인 project 관리를 해보진 않았지만 장점이면서 단점이 될것같다
-> 추측이긴하지만 springboot의 경우 모듈의 버전이 올라갔을 때 대대적인 변경사항이 발생하면 해당 부분에 대해서 바로 코드 수정 및 배포작업이 필요하지 않을까?

그 외 springboot의 장점으로는 spring-security, spring-data-jpa 등의 다른 framework를 간편하게 사용할 수 있게 한다는 점이다.

결론
. springboot와 springMVC는 각기 다른 개념이라서 각각에 대한 장단점을 비교하기에는 약간의 무리가 있다.
. springboot는 spring의 설정을 간편하게 해주는 framework, springMVC는 spring 기반의 web App개발용 framework이기 때문에 같은 위치,역할이 아니다.

ps : springboot, spring-web, spring-security 등을 사용하여개인 토이 프로젝트 진행중에 개념정리하려고 포스팅 함.

@SpriongBootApplication
 . Springboot 를 실행하기 위한 중요한 역할을 담당한다
 . Springboot의 기본적인 설정이 선언되어 있다.

@Target(ElementType.TYPE)
@Retention(RetentionPolicy.RUNTIME)
@Documented
@Inherited
@SpringBootConfiguration
@EnableAutoConfiguration
@ComponentScan(excludeFilters = { @Filter(type = FilterType.CUSTOM, classes = TypeExcludeFilter.class),
		@Filter(type = FilterType.CUSTOM, classes = AutoConfigurationExcludeFilter.class) })
public @interface SpringBootApplication {
 ....
 }

위 처럼 여러가지 meta Annotation 을 포함한다.
 - meta annotation ; 다른 annotation 을 정의하는데 사용되는 annotation을 의미
 
@Target
 . java complier가 해당 annotation이 적용될 대상을 결정할 때 사용된다.
 . 위의 코드를 보면 @SpringBootApplicaction의 target을 type으로 지정하고 있다.
 . ElementType은 PACKAGE, TYPE 등등이 존재한다.
 
@Retention
 . 해당 Annotation이 실제로 적용되고 유지되는 범위, 즉 해당 annotation의 lifecycle을 의미한다.
 . RUNTIME, CLASS, SOURCE 3가지가 존재한다.
 . @Retention(RetentionPolicy.RUNTIME)
 - compile 이후에도 JVM에 의해서 계속 참조가 가능하다.
 . @Retention(RetentionPolicy.CLASS)
 - Complier가 class를 참조할 때까지 유효하다.
 . @Retention(RetentionPolicy.SOURCE)
 - Complire 전까지만 유효하며, complier 이후에는 사라지게 된다.
 
=> 좀더 자세히
 . JVM은 Java source(.java 파일)를 complier가 complie 후에 Java byte code(.class 파일)로 변환한다.
위의  SOURCE는 .java까지 annotation이 남아 있다는 것이고, CLASS는 .class 까지,
RUNTIME은 runtime 환경에서까지 남는다는 것이다.
RUNTIME 은 실행중에도 annotation의 정보를 확인할 수 있다.
SORUCE의 경우는 특정 byte code를 생성한 후 .class에서는 사라지기며, lombok의 Getter, Setter를 예로 들 수 있다.
CLASS의 경우 Maven / Gradle을 통해 다운 받은 lib등의 jar 파일에는 source가 포함되어 있지 않기 때문에 필요하다.
 
@Documented
 . javadoc으로 api 문서를 만들 때 annotation에 대한 설명도 포함하도록 지정하는 역할을 한다.
 
@Springbootconfiguration

@Target(ElementType.TYPE)
@Retention(RetentionPolicy.RUNTIME)
@Documented
@Configuration
@Indexed
public @interface SpringBootConfiguration {
 .....
}

 . @Springbootconfiguration의 세부 사항을 보면 위의 코드와 같이 meta annotation으로 구성되어 있다.
이 중 @Configuration 이 중요한데 @Configuration 이 존재할 때 spring은 java configurure 설정 class로 간주하며 Bean으 로 등록하게 된다.

@Inherited
. 해당 annotation이 붙은 경우 자식 class까지 annotation을 상속하게 된다.
 

springboot 에서 cookie와 session 을 어떻게 사용하는지에 대해서 간단한 code를 통해 알아보자.

cookie의 추가

.....

@GetMapping("/tmp")
public String tmp(HttpServletRequest req, HttpServletResponse res)
{
  ....
  Cookie newCookie = new Cookie("cname", "cval");
  newCookie.setMaxAge(60); //60 seconds
  newCookie.setSecure(true);
  res.addCookie(newCookie);
  ......
  return "somthing";
}

 사용법은 단순하게 Cookie 생성 후 해당 Cookie의 각 속성에 대해서 지정한 후 response에 포함시켜 전달하면 된다.

cookie 내용 확인

....

@GetMapping("/tmp")
public String tmp(@CookieValue String email, @CookieValue("username") String username)
{
 //해당 Annotation 을 통해 접근 가능.
  return "something";
}

@GetMapping("tmp2")
public String tmp2(HttpServletRequest request)
{
 ....
 var cookies = request.getCookies();
 for(var coookie : cookies)
 {
   var cname= cookie.getName();
   var cval = cookie.getValue();
   // do something
 }
 return "something";
}

spring boot 에서는 위처럼 Annotation을 활용하거나 request에 직접 접근하여 cookie를 확인하는 방법이 존재한다.

session에 접근하기

.....

@GetMapping("tmp")
public String tmp(HttpServletRequest request)
{
 ....
 HttpSession session = request.getSession();
 //session에 특정 정보 추가하기
 session.addAttribute("someKey", "thisValue");
 ........
 
 return "something";
}


@GetMapping("tmp2")
public String tmp2(HttpServletRequest request)
{

  ......
  var session = request.getSession(false);
  //false인 경우 해당 요청에 session 이 존재하지 않을때 null을 반환
  if(session == null)
  {
    session = request.getSession(true);
    //true인 경우 session 이 없으면 새로운 session 을 생성& 반환.
  }
  return "smoethig";
}

@GetMapping("tmp3")
public String tmp3(@SessionAttribute(name="someKey", required=false) String thisValue)
{
  //session에 someKey에 대한 정보가 없는 경우 thisValue는 null
  
}

springboot에서는 위처럼 간단하게 session 정보에 대해서 접근 및 가공이 가능하다.

개인 공부용 포스팅입니다. 틀린 내용이 포함되어 있을 수 있으니 적당히 거르고 검증하시길 바랍니다.

틀린 내용은 댓글로 알려주시면 확인 후 반영하겠습니다.

세션이란 무엇인가?

 - 웹에서 사용자의 정보를 저장하는 방법을 의미한다.

 - 또 다른 의미로는 사용자가 브라우저를 닫기전까지 연결이 유지되는 상태를 의미하기도 한다.

Session은 server에 사용자의 중요한 정보를 저장하고 이에 대한 id값을 cookie에 전달하여 

실제 사용자가 해당 id를 통해 사용자 정보에 접근할수 있게 해준다.

기존 Cookie를 활용하는 방법보다는 보안성 측면에서 훨씬 안전하다.

일반적인 Session 과정

 - 사용자가 server 에 접속

 - server는 해당 요청 속 JSESSIONID header가 존재하는지 여부를 확인

 - 없다면 새로운 session id를 발급

 - 발급된 session id를 response의 JSESSIONID Header에 저장

 - 이후 요청에는 신규발급된 session id가 포함되어 요청됨

 - 사용자의 로그인 요청

 - 해당 유저의 로그인 정보 확인

 - 확인 후 적합한 로그인 요청이었다면 해당 회원에 대한 session 정보 생성

 - 각 요청에 대해서 server는 session id를 통해 해당 유저의 session data를 활용

   -> 해당 유저의 요청에 대해서 authentication, authorization 등을 검증 시 활용.

참고 : 해당 JSESSIONID cookie는 session cookie이므로 브라우저와의 접속이 끊길 시 자동으로 사라진다.

참고2 : JSESSIONID cookie에 대해서 별도의 만료기간을 지정할 수 있다.

세션의 실제활용 예

 - 로그인을 한 유저인지 판별

 - 로그인 후 특정 권한에 대한 정보 식별

 - 특정 page에 접근 시 권한 확인.

 - 유저가 로그아웃 시 새로운 session id를 발급.

세션의 단점

 - 기본적으로 cookie보다는 보안성이 좋지만 특정 유저의 session id를 탈취당하면 보안이슈가 발생할 수 있다.