스프링의 정석으로 충분한 내용들은 기록하지 않고, 지금 나에게 필요한 정보만 담는다...

Spring MVC 파트

• 요구사항에 맞춰서 애플리케이션의 기능을 특정 범위로 제한하는 것을 애플리케이션 경계를 설정한다 라고 말한다.
• 클라이언트의 요청사항을 구체적으로 처리하는 영역을 서비스 계층(Service Layer)라고 한다.
• 요구 사항을 처리하기 위해서 Java코드로 구현한 것을 비즈니스 로직(Business Logic)이라고 한다.
• JSON의 기본 포맷
  • {"속성":"값"}
• 패키지 구조
  • 기능 기반 패키지 구조
    • 하나의 기능을 완성하기 위한 계층별(API 계층, 서비스 계층, 데이터 액세스 계층)클래슬이 모여있는 구조.
  • 계층 기반 패키지 구조
    * 패키지를 하나의 계층(Layer)으로 보고 클래스들을 계층별로 묶어서 관리하는 구조

    참고!
    Spring Boot는 테스트와 리팩토링이 용이하고, 향후에 마이크로 서비스 시스템으로의 분리가 상대적으로 용이한 기능 기반 패키지 구조 사용을 권장한다.

@SpringBootApplication , @RestController

@SpringBootApplication

• Spring Boot 기반의 애플리케이션의 엔트리 포인트를 지정하는 애너테이션.
  *하는 일 3가지
  • 자동 구성을 활성화
  • 애플리케이션 패키지 내에서 @Component가 붙은 클래스를 검색한 후(scan), Spring Bean으로 등록하는 기능을 활성화한다.
  • @Configuration이 붙은 클래스를 자동으로 찾아주고, 추가적으로 Spring Bean을 등록하는 기능을 활성화한다.

@RestController

• 해당 애너테이션을 추가하면, 클래스가 REST API의 리소스를 처리하기 위한 API 엔드포인트로 동작함을 정의한다.
• 해당 애너테이션이 추가된 클래스는 애플리케이션 로딩 시, Spring Bean으로 등록해준다.

@RequestMapping의 produces 속성

produces는 응답 데이터를 어떤 미디어 타입으로 클라이언트에 전송할 지 설정한다.
JSON형식으로 전송하려면,
produces = {MediaType.APPLICATION_JSON_VALUE}
를 주면 된다.

그건 그렇고, 이 내용 관련해서, Controller의 실습을 했다..
Controller로 지정한 클래스 안에 요구사항에 맞는 메서드를 구현하는 것...

느낀 점...
이건 매번 느끼는 거지만,
오타를 잘 잡자...;;

그리고 주소창의 매핑에 long값을 받게 했는데,
long타입은 값의 뒤에 L이 붙는다..
근데, 예를 들어서, memberId가 있다고 가정하고, memberId가 1인 member를 어째어째 해라는 게 요구사항이다..?

그래서 PostMan(HTTP 요청을 좀 쉽게 들여다 볼 수 있는 프로그램)으로 주소창에 1L을 계속 줘도 안되더라..?
그래서 데이터가 Map으로 되있었는데, Map안에 value가 또 Map이었다..;;
이것도 내가 삽질하는데 한 몫했다... 결과가 제대로 안 나오길레, Map을 어렵게 생각했고, Map을 내가 잘 못이해했나..? 싶었는데,,

하.. 뭐지? 하다가 PostMan의 주소창에 우연찮게 1L 중에서 L이 지워졌고! 나도 모르게 SEND를 클릭!했는데......
결과가 제대로 나왔다....

그래.. 그렇다... 현타 겁나 왔다..
다음부터 long이라도 주소창에 접미사붙이는 불상사는 안벌이기로...마음을 먹은 계기였다..

역시 나는 그럼에도 불구하고, 잘 되고 있다!!
퐈이링~!