MethodArgumentNotValidException은 스프링에서 제공하는 사용자 정의 예외라는것을 알았다.
오늘 발표자료를만드는데.. 내가한것이 거의 없었지만.. 다들 열심히했다.(나빼고)
그래도 내가 발표했긴했는데 잘했는지 모르겠지만, 다음에는 더 잘해보자
다른발표조들의 페이징이랑 스케쥴링, 그리고 git사용을 보니 다음에는 문제있는부분 커밋할때 issue를 활용할수있도록 #으로 번호를 넣어줘야겠다.
@AuthenticationPrincipal의 원리말고.. 하는역할 짧게
@AuthenticationPrincipal어노테이션이 하는역할
스프링 시큐리티가 제공해주는 기능 중에 하나로 스프링 MVC 핸들러 파라메터에 @AuthenticationPrincipal를
사용하면 getPrincipal() 로 리턴 받을 수 있는 객체를 바로 주입받을 수가 있다고 한다.
있는 지 없는지만 확인하는 용도로 사용
인증 안한 경우에 null
인증 한 경우에는 username과 authorities 참조 가능
@RequiredArgsConstructor
//의존성주입으로 사용,
//final을 가지고 있는 속성에 롬복에의해 자동으로 생성자를 만들어줌
@RestController//CONTROLLER VS RESTCONTROLLER 두개의 차이점
Json형태로 반환하는것이 없는메소드가 더 많다면 @Controller와 @ResponseBody를 조합이 좀더 좋을것같다. @RestController는 모든 메소드의 위에@ResponseBody를 적어주기 때문이다.
클라이언트 -> 서버 통신 : Request, 서버-> 클라이언트 통신 : Response.
새로고침 없이 이루어지는 통신 : 대부분 비동기 통신(클라->서버 요청시 본문에 데이터(JSON) 담아서, 서버->클라 응답시 본문에 데이터 담아서.
이 본문들이 RequestBody, ResponseBody.
@RequestBody, 클라가 전송하는 JSON 형태의 HTTP Body 내용을 Java 객체로 변화시켜줌. JSON 형태의 HTTP Body가 없는 get, delete 등 메소드에 @Requestbody 쓰면 에러 발생
@GetMapping과 @PostMapping 어노테이션은 @PutMapping, @DeleteMapping, @PatchMapping과 함께 스프링 4.3부터 등장했다. 왜 @RequestMapping 대신 @PostMapping 등등을 쓸까 ?
1.코드가 줄어듬
2.url중복 사용가능
3.코드에 의미명시(GET 화면에 뿌릴떄, POST 전송 데이터 insert 할 때 등등 ex.@RequestMapping(value="경로", method=RequestMethod.GET) -> @GetMapping("경로")
@RequestParam :
요청 파라미터를 메소드 파라미터에 넣어줌
ex. /board/detail?boardId=${boardId}
**사용시, 파라미터 넘기지 않으면(null)시에 400에러 !
그래서 꼭 required = false 넣어야 함
@PathVariable : @RequestMapping의
URL에서의 ({})의 명시된 변수를 받아온다.
+ @PathVariable을 이용해서 URI 템플릿 중에서
어떤 파라미터를 가져올 지 결정 가능 ex.
/board/detail/${boardId} @slf4j, @Lof4j, @logback 의존성을 알아서 입력해준다
일일이 기록해준다
우테코톡 Logging이 뭐냐 배포환경에서 확인하는거
sout -> Test코드 ->로깅
로깅 프로그램동작시 발생하는 모든 일을 기록하는 행위
로그 레벨 ->
4.fatal 프로그램이 종료되는 에러
3.warn 잠재적위험 의도한 에러상태변경
2.정보메시지 info
1.debug 개발환경 tarce
