[WIL] 3주차 개발 일지

민지·2022년 5월 29일

WIL

목록 보기

3/4

MVC

HTTP 메시지
헤더랑 바디가 나누어져 있고 스타트라인이 나누어져있다.

Request

시작줄: API 요청 내용, url, 버전
헤더: Content type : 들어갈수도 있고 안들어 갈 수도 있다. html 태그로 요청, ajax요청: json형태로 요청을 보냄
바디: 실제로 클라이언트가 보내는 내용, Get 요청 시: 보통 없음, post 요청 시: 사용자가 입력한 폼 데이터

Reponse

상태줄: API 요청 결과, 상태코드: 서버에서 클라이언트요청을 어떻게 처리했는지 결과를 보여주는 것
헤더: content type: 없음, 본문 내용이 HTML인 경우: text/html, json인경우: application/json
Location: Redirect할 페이지 url
본문: HTML, JSON

정적 웹페이지

static 폴더 하위 html

동적 웹페이지

templates 폴더 하위 html

@GetMapping("/html/templates")
  public String htmlTemplates() {
      return "hello";
  }

hello 스트링을 리턴
스트링이 hello를 view name으로 전달
타임리프 default 설정
prefix: templates 폴더에서 찾아라 이 view를 찾으면 hello 스트링을 중심으로 앞에는 /templates/ 가 붙고

Suffix:.html
뒤에는 html

@GetMapping("/body/html")
  @ResponseBody
  public String helloStringHTML() {
      return "<!DOCTYPE html>" +
              "<html>" +
              "<head><meta charset=\"UTF-8\"><title>By @ResponseBody</title></head>" +
              "<body> Hello, 정적 웹 페이지!!</body>" +
              "</html>";
  }

@ResponseBody 추가-> view를 제공하는 것이 아니라 이 스트링 내용을 바디에 채워줘 라는 뜻
content type: text/html ->헤더 내용
바디에는 html 내용이 들어옴 그 내용이 response에 들어온 것 이 부분이 바디가 됨 return 된 내용이 여기에 그대로 들어옴

@ResponseBody를 추가하면 view를 통과하지 않는다. 템플릿 엔진으로 넘기는게 아니라 이 메시지를 본문(바디로) 넘겨준다.

@GetMapping("/html/dynamic")
  public String helloHtmlFile(Model model) {
      visitCount++;
      model.addAttribute("visits", visitCount);
// resources/templates/hello-visit.html
      return "hello-visit";
  }
private static long visitCount = 0;

방문자수가 동적으로 바뀜
한번 요청이 올 때마다 visitConut 증가.
view 정보는 hello-visit model 정보 둘다 타임리프에게 전달, 타임리프에서 합쳐짐
view 정보: "hello-visit"-> resources/templates/hello-visit.html
model 정보: visits(visitCount) 방문횟수

    @GetMapping("/json/string")
    @ResponseBody
    public String helloStringJson() {
        return "{\"name\":\"BTS\",\"age\":28}";
    }

response content type : text/html
html 내용을 내린 것이아니라 response 바디에다 json 내용을 내렸는데 content type이 application/json이 아니라 text/html
사실은 잘못된 형태
```
  @GetMapping("/json/class")
  @ResponseBody
  public Star helloJson() {
      return new Star("BTS", 28);
  }
```
response content type: application/json

servlet을 사용할때는 java객체를 json형태로 변환하는 것을 직접 바꿔줘야 했었는데 spring에서는 json 형태를 어떻게 만드는지에 대해 신경쓰지않고 그냥 객체만 넘겨주면 알아서 json형태로 바꿔줌

@Restcontroller

현재 동적웹페이지와 json데이터를 많이 사용하게 됨
클라이언트요청을 할때 처음에만 html을 내려주고 그 이후로는 데이터만 왔다갔다 주고 받음 -> 싱글페이지 애플리케이션 개념
항상 @Controller와 @ResponseBody를 붙여줘야했는데 그래서 나온 것

@ResponseBody: json을 내릴 때 주로 사용

@RestController
@RequestMapping("/hello/rest")
public class HelloRestController {

    @GetMapping("/json/string")
    public String helloHtmlString() {
        return "<html><body>Hello @ResponseBody</body></html>";
    }
    @GetMapping("/json/list")
    public List<String> helloJson() {
        List<String> words = Arrays.asList("Hello", "Controller", "And", "JSON");

        return words;
    }
}

원래 string을 내려주는 경우에는 템플릿 엔진을 통해 view로 전달하는 것인데
@RestController을 붙여주면 자동으로 메소드 윗 부분에 @ResponseBody가 추가 되는 것이라고 볼 수 있다.

MVC 동작 원리

클라이언트요청 -> DispatcherServlet (frontcontroller): API를 처리해 줄 controller를 찾아서 그 요청을 전달(Handler mapping에는 path와 controller 함수가 매칭 되어있음, controller에서 mapping 한 정보들을 다 모아놓음, 즉 Handler mapping을 통해 어느 controller에 전달해야하는지 알 수 있음)-> controller->Dispathces

GET: 주소창에 정보가 들어감
POST: 주소창에 정보를 숨기고 바디에 들어감

의존성 주입의 이해

강한 결합
느슨한 결합 -> controller, service, repository 연결 과정에서 new를 한번만 사용하여 재사용하는 것

DI 의존성 주입

제어의 역전 IoC: Inversion of Control
프로그램의 제어 흐름이 뒤바뀜(강한결합-> 느슨한 결합)
용도에 맞게 필요한 객체를 그냥 가져다 사용
사용할 객체가 어떻게 만들어졌는지 알 필요도 알 수도 없음->느슨한 결합의 장점

IoC 컨테이너

DI 주입을 위해 등록되어있는 Bean을 모아 관리하는 컨테이너
@Autowired를 통해 필요할 때마다 Bean을 가져다 사용

인증 및 인가

인증: 사용자 신원을 확인하는 행위(ex 회사 건물 출입증, 아이디와 패스워드 등)
인가: 사용자 권한을 확인하는 행위(ex 회사 건물 내 접근 권한 권리, 회원 랭킹 별 접근 가능한 게시물 등)

쿠키와 세션

http가 상태를 저장하지 않는다는 특징을 가지고 있음
클라이언트가 서버에 request하고 response 받고 나서, 다시 한번 더 request하고 response 받을 때, 내가 첫 번째 보냈던 요청과 같은 사용자라는 것을 알 수 없다.

그럼 어떻게 로그인을 유지하지?

이때 사용되는 것이 쿠키와 세션
-> http에 상태 정보를 유지

쿠키

클라이언트에 저장, 작은 정보를 담은 파일(ex 오늘 다시보지 않기 팝업)
- name : 쿠키를 구별하는 데 사용되는 키(중복될 수 없음)
- Value: 쿠키의 값
- Domain: 쿠키가 저장된 도메인
- Path: 쿠키가 사용되는 경로
- Expires: 쿠키의 만료기한(만료기한이 자나면 삭제됨)

세션

클라이언트가 서버에 1번 요청-> 서버가 세션 ID를 생성, 응답 헤어에 전달-> 클라이언트가 쿠키 저장-> 클라이언트가 서버에 쿠키값 포함하여 2번 요청-> 서버가 세션 ID확인하고, 1번 요청과 같은 클라이언트임을 인지

서버에 저장, 클라이언트의 상태를 유지(ex 로그인 정보)
서버에서 클라이언트 별로 유일무이한 세션 ID를 부여한 후 클라이언트 별 필요한 정보를 서버에 저장
서버에서 생성한 세션 ID는 클라이언트의 쿠키값(세션 쿠키)으로 저장되어 클라이언트 식별에 사용
세션에 저장하려면 결국 쿠키가 필요

스프링 시큐리티 프레임워크

모듈 별로 잘 분리 우리가 원하는 기능만 잘 가져가다 레고처럼 조립해서 사용가능
서버에 필요한 인증 및 인가를 위해 많은 기능을 제공

2주차 때는 강의를 들으면서 스프링의 전체적인 흐름이 뚝 뚝 끊기는 느낌이었다면, 이번 주에는 코드의 생략된 부분을 구체적으로 알게 되면서 흩어져 있던 개념들이 하나씩 연결되는 느낌을 받았다. 혼자서 코드를 짜보면서 다시 한번 개념과 흐름을 되짚어봐야 할 것 같다.

민지

매일 매일 기록하기

이전 포스트

[WIL] 2주차 개발 일지

1개의 댓글

김하연

2022년 6월 12일

민지님 4주차 WIL 올려주세요 현기증나요

답글 달기