1. 어려웠던 부분  : 처음으로 스프링이란 녀석을 접하게 되었다. 사실 완전 처음은 아니고, 한달 전에 유튜버 홍팍 선생님의 스프링 입분강의를 12회 까지 들은 적은 있는데, 개념이 없는 상태로 흘려 들었던 터라 이번이 처음이나 다름 없었다. 아직 자바 클래스도 공부하지 않앗는데, 첫 발제된 날 부터 과제로 클래스 설계가 나와서 시작부터 당황스럽고 아무 개념없이 스프링 강의를 듣고 과제를 하려니 너무 막막했다. 인프런 김영한 선생님 강의도 들어보고 항해에서 제공해준 강의도 들어봤는데, 기본기가 없다보니 뭔가 제자리 걸음만 하는 기분이었다. 그래도 기술매니저님이 일단 과제를 빨리 시작해보라고 하셔서 죽이되든 밥이되든 해보자는 마음으로 시작했는데, 과제를 하고나서 코드에 주석을 달아보면서 그제서야 흐름을 조금 파악할 수 있었다.

2. 느낀 점 : 막막한 나의 과제에 또 한줄기 빛처럼 도움을 준 은솔님. 처음에 엔티티를 디티오로 반환하라는게 무슨말인지 와닿지 않기도 하고 어떻게 하는지 몰랐는데, 은솔님이 차근차근 따로 설명해주셔서 그제서야 이해할  수 있었다. 그리고 이번엔 조원들 중에 실력자분들이 많아서 코드 리뷰도 하면서 다른 사람의 코드를 통해 또 더 많은 걸 배울 수 있었다. 그래서 느낀 점은, 배움에 주변인이 참 중요하다는 것.

3. 새로 알게 된 내용 : 스프링의 기본 개념을 파악할 수 있었다. 아직 배워야 할 개념, 정리해야할 개념은 많지만 그래도 전반적인 틀인 컨트롤러, 서비스, 레포지토리 그리고 이들을 연결하는 디티오, 엔티티의 개념을 좀 알 것 같다. 아직 100%이해했다고 할 수 없지만, 일주일 동안 과제도 수행하고 대략적인 흐름을 파악한 것에 의의를 두기로 했다.

4. 셀프칭찬 (오늘 잘한 일) : 매주가 새롭고 힘든 항해99. 진짜 하루에 몇번이고 그만하고 싶다는 생각이 들었지만 그때마다 스스로 잘 하고 있다고 버티는게 승자라는 생각을 하며 멘탈을 잘 부여잡았다. 이제 정규 과정이 시작한지 3주차니까, 힘든 건 당연한거라 생각한다. 항해의 과정이 생각했던 것 보다 훨씬 어렵고 힘들지만, 그래도 어찌 저찌 헤쳐나가고 있는 나를 칭찬해주자. 시작했으니 끝은 봐야하니까 다음주의 나도 힘내길.

5. 이번주 할 일 : JPA, JWT, SQL 개념을 이번주에 확실히 잡자 ! + 입문주차에 정리 못했던 개념들 정리하기 + 어노테이션 정리 

[이번주 공부한 부분 링크 정리]

[19] JAVA 패키지와 접근 제한자

[20] JAVA 상속

[21] JAVA 타입변환과 다형성

[22] JAVA 추상클래스

[23] JAVA 인터페이스

[01] Spring Boot 기본 개념 알고 시작하자 !

[02] 항해99 주특기 입문 1주차 (1-1) - Use Case, API 명세서

[03] 항해99 주특기 입문 1주차 (1-2) - PostMan/h2-console

[04] 항해99 주특기 입문 1주차 (1-3) - 코드 흐름 읽어보기

[05] 항해99 주특기 입문 1주차 (1-4) - Delete 수정하기

[06] 항해99 주특기 입문 1주차 (1-5) - 팀과제 (키워드 정리)

[07] 항해99 주특기 입문 1주차 - 주특기 시험 (API 구현)

[08] 웹 동작방식

RESTful API 설계 가이드

1. 어려웠던 부분  : 오늘 어제 끝내지 못한 스프링 숙련주차 강의 후반부를 들었다. 인증 인가에 대한 내용과 페이징에 관한 내용이었다. JWT토큰은 토이프로젝트부터 계속 나오던 개념인데, 항상 내가 맡았던 파트가 아니라 해보기 전엔 이해가 어려운 것 같다. 쿠키와 세션 그리고 JWT 토큰의 차이점을 다시 정확히 이해할 필요가 있는 것 같고, 과제를 하면서 어떻게 코드에 사용해야하는지 파악해봐야 겠다.

2. 느낀 점 : 같이 공부하는 반 사람들은 물론이고, 기술매니저님 그리고 심지어 운영매니저님들 마저 모두가 열심히 새벽까지 공부하는 항해99. 인생에서 이렇게 늦게까지 열심히 했던 적은 수능 이후 처음인 것 같다. 그치만 진짜 페이스 조절이 필요한 시점이 아닌가 싶기도 하다. 내 속도를 지키고 무리하지 말자는 다짐을 하게된 하루.

3. 새로 알게 된 내용 : 인증(Authentication) - 해당 유저가 실제 유저인지 인증하는 개념, 인가(Authorization) - 해당 유저가 특정 리소스에 접근이 가능한지 허가를 확인하는 개념. 인증과 인가에 대한 내용을 배우고, JWT토큰의 장점, 그리고 사용하는 법을 강의를 통해 배웠다. 과제를 수행하면서 다시 한번 익숙해 져야겠다.

4. 셀프칭찬 (오늘 잘한 일) : 목표했던 스프링 숙련주차 강의를 끝냈다! 예 ! 

5. 내일 할 일 : 시간이 된다면 과제 시작하기. WIL 작성하기.

[오늘 공부한 부분]

• 지난주차 스프링 입문 강의 복습
• 스프링 숙련주차 강의 끝까지 마무리
• 자바 언어스터디 ( 추상클래스)
• 김준규 기술매니저님 Controller 세션 
• 혼자 공부하는 자바 - 8강 인터페이스

[08] 웹 동작방식

[22] JAVA 추상클래스

[23] JAVA 인터페이스

스프링 MVC 이해 - Response

스프링 MVC : MVC (Model - View - Controller) 디자인 패턴

• View: 동적 HTML 파일
• Model: View 에 적용할 정보들

Server 에서 HTML 을 내려 주는 경우

① 정적 (static) 웹 페이지

• Controller
  • Client 의 요청을 Model 로 받아 처리
  • 예) 회원가입을 위한 개인 정보들 (id, password, name)
  • Client 에게 View (정적 웹 페이지, HTML) 를 내려줌

② 동적 (dynamic) 웹 페이지

• Controller
  • Client 의 요청을 Model 로 받아 처리
  • Template engine 에게 View, Model 전달
  • Template engine
    • View 에 Model 을 적용 → 동적 웹페이지 생성 ,
    • 예) 로그인 성공 시, "로그인된 사용자의 id" 를 페이지에 추가
  • Template engine 종류: 타임리프 (Thymeleaf), Groovy, FreeMarker, Jade 등 (스프링에서 JSP 이용은 추천하지 않고 있음)
  • Client 에게 View (동적 웹 페이지, HTML) 를 내려줌

Controller 와 HTTP Response 메시지

@Controller

@Controller 는 스프링 서버 개발자 입장에서는 시작점과 끝점으로 보이지만, 사실 스프링이 뒤에서 많은 부분을 보이지 않게 처리한다.

① Client → DispatcherServlet

1. 가장 앞 단에서 요청을 받아 FrontController 라고도 불림

② DispatcherServlet → Controller

• API 를 처리해 줄 Controller 를 찾아 요청을 전달
• Handler mapping 에는 API path 와 Controller 함수가 매칭되어 있음

③ Controller → DispathcerServlet

1. Controller 가 Client 으로 받은 API 요청을 처리
2. 'Model' 정보와 'View' 정보를 DispatcherServlet 으로 전달

④ DispatcherServlet → Client

1. ViewResolver 통해 View 에 Model 을 적용
2. View 를 Client 에게 응답으로 전달

스프링 MVC 이해 - Request

< Controller 와 HTTP Request 메시지 >

자료 출처 : 스파르타 코딩클럽 - 스프링 숙련주차 강의자료

웹의 동작방식

IP 주소란?

• 거대한 네트워크망에서 컴퓨터를 식별하기 위한 위치 주소 
• 네트워크상에서의 데이터 송/수신은 이 주소를 기준으로 이루어지고 있다.

브라우저란?

• 크롬, 사파리, 엣지와 같이 웹페이지, 이미지, 비디오등의 컨텐츠를 송/수신하고 표현해주는 소프트웨어
• 브라우저의 역할 : 컨텐츠를 송/수신, 컨텐츠를 표현
• 브라우저는 메세지가 OSI 7 계층을 거쳐 랜선을 통해 0과 1로 변경되어 흘러갈 수 있도록 도와주는 응용프로그램이자, 클라이언트와 상호작용해서 요청을 보내는 응용프로그래밍 계층의 첫 출발점

DNS(Domain Name Server)란?

• IP주소 대신 abcdefg.com과 같은 도메인 이름 을 입력해서 원하는 웹 사이트로 이동하게 해주는 역할
• 요청을 받아줄 서버의 IP주소(192.168.0.123)와 도메인 이름을 사이를 중개해주는 중개 서버

HTTP란 ??

• 멀리 떨어져서 서로에 대한 정보가 없는 메세지의 송/수신자가 서로 필요한 요청과 응답을 할 수 있도록 미리 규약을 정해놓은 것을 프로토콜이라고 하고, 웹 상에서는 HTTP 라는 프로토콜을 통해서 데이터를 송/수신 하고 있다.

API(application programming interface)

• 다른 소프트웨어 시스템과 통신하기 위해 따라야 하는 규칙
• 개발자는 다른 애플리케이션이 프로그래밍 방식으로 애플리케이션과 통신할 수 있도록 API를 표시하거나 생성한다.
• 웹 API는 클라이언트와 웹 리소스 사이의 게이트웨이라고 생각할 수 있다.

인터페이스(interface)

• 서로 다른 두 개의 시스템, 장치 사이에서 정보나 신호를 주고받는 경우의 접점이나 경계면이다.
• 즉, 사용자가 기기를 쉽게 동작시키는데 도움을 주는 시스템을 의미한다.
• 컴퓨팅에서 컴퓨팅 시스템끼리 정보를 교환하는 공유 경계이다. 이러한 교환은 소프트웨어, 컴퓨터 하드웨어, 주변기기, 사람간에 이루어질 수 있으며, 서로 복합적으로 이루어질 수도 있다.

RESTful API란?

Representational State Transfer(REST)는 API 작동 방식에 대한 조건을 부과하는 소프트웨어 아키텍처입니다. REST는 처음에 인터넷과 같은 복잡한 네트워크에서 통신을 관리하기 위한 지침으로 만들어졌습니다. REST 기반 아키텍처를 사용하여 대규모의 고성능 통신을 안정적으로 지원할 수 있습니다. 쉽게 구현하고 수정할 수 있어 모든 API 시스템을 파악하고 여러 플랫폼에서 사용할 수 있습니다.

• 서버의 api가 적절하게 http를 준수하며 잘 설계되어있으면 RESTful 하게 설계되어 있다는 것
• 예를들어 api의 리소스 식별자를 ex - (”/”) 중복 없이 고유하게 잘 만들고,
• 해당 api에 적절하게 http메서드를 사용했다면, RESTful하게 설계했다고 볼 수 있다.

데이터베이스

데이터베이스는 데이터를 “효율적으로 성능 좋게” 다루기 위해 존재합니다.

즉 더 많이 저장하기 위해서가 아니라, 저장 조회 수정 삭제등을 더 빠르고 효율적으로 처리하기 위해서, “성능상의 이점”을 얻기 위해서 사용한다고 생각하면 좋을 것 같습니다.

이러한 맥락에서 데이터를 사용,활용하는 주체에 따라서 더 효율적인 방법이 각각 다르다 보니 다양한 형식의 데이터베이스가 존재하게 됩니다.

결론

결론적으로 서버 개발에서 그래도 가장 많이 하는 일은, “새로운 정보”와 “기존의 정보”를 가지고 “정해진 로직”을 수행하는 일

인터페이스

• 인터페이스 : 개발 코드와 객체가 서로 통신하는 접점 역할
• 개발 코드가 인터페이스의 메소드를 호출 → 인터페이스는 객체의 메소드를 호출
• 인터페이스를 통해 개발 코드를 수정하지 않아도 사용하는 객체를 변경하는 방법을 통해 실행 내용과 리턴값을 다양화 할 수 있다.

인터페이스 선언

• 인터페이스의 물리적 형태는 클래스와 동일하다. 그러나 소스를 작성할 때 선언하는 방법에 클래스와 차이가 있다.
• 인터페이스 이름은 클래스 이름을 작성하는 방법과 동일하다. ( 첫 글자를 대문자로 나머지는 소문자로)
• 인터페이스는 class 키워드 자리에 interface 키워드를 사용한다.

• 인터페이스는 상수 필드와 추상 메소드만을 구성 멤버로 갖는다.
• 인터페이스는 객체로 생성할 수 없기 때문에 생성자를 가질 수 없다.

① 상수 필드 선언 

• 인터페이스는 데이터를 저장할 수 없기 때문에 상수 필드만 선언할 수 있다.
• 상수 필드는 기본적으로 public static final 특성을 갖는다.
• 관례적으로 필드 이름은 모두 대문자로 작성해야 하며, 선언 시 초기값을 대입해야 한다.

② 추상 메소드 선언

• 인터페이스로 호출된 메소드는 객체에서 실행되므로 추상 메소드로 선언한다.
• public abstract가 생략되고 메소드 선언부만 있는 추상 메소드 형태이다.
• 구현 클래스는 반드시 추상 메소드를 재정의해야 한다.

인터페이스 구현

• 인터페이스에서 객체의 메소드를 호출할 때, 객체는 인터페이스에 정의된 추상 메소드와 동일한 메소드 이름, 매개 타입, 리턴 타입을 가진 실체 메소드를 가지고 있어야 한다.
• 이런 객체를 인터페이스의 구현(implement)객체라고 하고, 구현 객체를 생성하는 클래스를 구현 클래스라고 한다.

① 구현 클래스

• 보통의 클래스와 동일한데, 클래스 선언부에 implements 키워드를 추가하고 인터페이스 이름을 명시한다.
• 그리고 인터페이스에 선언된 추상 메소드의 실체 메소드를 선언해야 한다.
• 주의점 : 인터페이스의 모든 메소드는 기본적으로 public 접근 제한을 갖기 때문에, public보다 낮은 접근 제한으로 작성할 수 없다.
• 인터페이스로 구현 객체를 사용하려면 다음과 같이 변수를 선언하고 구현 객체를 대입해야 한다.

② 다중 인터페이스 구현 클래스

• 객체는 그림과 같이 다수의 인터페이스 타입으로 사용할 수 있다.
• 구현 클래스는 모든 인터페이스의 추상 메소드에 대해 셀체 메소드를 작성해야 한다. 

인터페이스 사용

• 클래스를 선언할 때 인터페이스는 필드, 생성자 또는 메소드의 매개 변수, 생성자 또는 메소드의 로컬 변수로 선언될 수 있다.
• 인터페이스가 필드 타입으로 사용될 경우 : 필드에 구현 객체를 대입할 수 있다.
• 인터페이스가 생성자의 매개 변수 타입으로 사용될 경우 : new 연산자로 객체를 생성할 때 구현 객체를 생성자의 매개값으로 대입할 수 있다.
• 인터페이스가 로컬 변수 타입으로 사용될 경우 : 변수에 구현 객체를 대입할 수 있다.
• 인터페이스가 메소드의 매개 변수 타입으로 사용될 경우 : 메소드 호출 시 구현 객체를 매개값으로 대입할 수 있다.
• 대입이 된 후에는 재정의된 구현 객체의 메소드를 호출할 수 있다.