23.12.18 스프링 입문!
참고로 아래에 노란색은 답, 빨간건 내가 선택한 오답이다. 이것은 주말에 살짝 선행학습했던 스프링 기초에 대한 입문 문제다!
1. Library 와 FrameWork의 설명 중 틀린 것을 고르시오*
① 특정한 언어의 개발 환경에 기본적으로 포함된 것들은 대부분 표준 Library라고 불린다.
② Library는 Application을 호출하는 Caller 역할을 한다.
③ 이유: 프레임워크 어플 라이브러리 순이다.
④ FrameWork는 개발 시 목적에 따라 고민할 필요 없이 이용할 수 있도록 일괄로 가져다 쓰도록 만들어 놓은 틀이다.
⑤ Spring 은 Library가 아닌 FrameWork이다.
2. CSR(Client Side Rendering) 특징 중 올바른 것을 고르시오*
① SEO가 가능하다.
② 사용자가 첫 화면을 보는데 시간이 적게 걸린다.
③ 서버의 부하를 줄여줄 수 있다.
④ CSR은 보통 Multi Page Application에서 사용되는 기법이다.
3. SSR (Server Side Rendering) 의 특징 중 올바른 것을 고르시오*
1.서버의 부하가 적다.
2.SEO가 가능하다. 난이거였는데 빠른거지 가능은 csr도 가능했다.
3.서버측에서 데이터를 가져와서 페이지를 구성한다.
4.사용자가 느끼기에 첫 화면이 느리게 느껴진다.
4. JSON에 대해 틀린 것을 고르시오*
① Javascript 객체 문법으로 구조화된 데이터를 표현하기 위한 문자 기반의 표준 포맷이다.
② Public Key - Private Key 구조로 되어 있다. 키를 사용하긴 한데 저건 암호화의 키라 관계없다.
③ JSON은 데이터를 네트워크를 통해 전송할 때 유용하다.
④ JSON은 Javascript의 기본 데이터 타입을 담을 수 있다.
5. Web Application을 만들기 위해 필요한 요구사항에 대해 틀린 것을 고르시오
*
① 특수한 상황에 대한 예외처리가 필요하다.
② 스토리지와 내부 시스템과 통신할 수 있어야 한다. 외부시스템이다.
③ 비즈니스 로직을 처리할 수 있어야 한다.
④ 인증과 인가 처리를 할 수 있어야 한다.
⑤
6. DI(Dependency Injection)의 방법중 틀린 것을 고르시오
*
① Field Injection
② Setter Injection
③ Constructor Injection
④ Class Injection 이런건 없다. 위의 세개뿐
7. IoC(Inversion of Control) 의 장점 중 틀린 것을 고르시오*
① 애플리케이션 코드의 양을 줄일 수 있다.
② 클래스 간의 결합을 강하게 한다. 약하개하는건 DI다
③ 애플리케이션의 테스트와 유지 관리를 쉽게 해준다.
④ 유연한 코드를 작성 할 수 있는 구조가 될 수 있다. IoC는 클래스를 강하게해서 유연하지 않나보다
8. 생성자 주입 방식이 가장 권장되고 있는 이유는 무엇일까요?
의존되는 객체의 불변성 확보, 순환 참조 방지, 테스트 코드 작성의 용이 의 세가지 이유가 있는데, 이중 불변성 확보가 가장 중요하다. 왜냐면 생성자 주입 방식만이 val을 써서 불변성을 확보했기 때문이다.
ddd란 기획자랑 소통 도구
전략적 설계와 전술적 설계로 나뉘는데, 우리가 해야할건 전략적 설계.
Ubiquitous Language: 공통된 언어(단어)를 통해 개발자와 도메인 전문가를 포함한 팀원들 간에 일관된 용어를 사용하자는 개념. 마케팅을 누군 미팅이란 의미로 쓴다면 대화가 안되니까.
Actor: 도메인에 속해있는 사용자. 어플의 관리자, 어플을 사용하는 남자,여자가 있으면 액터는 셋
Domain Event: 도메인에서 발생하는 사건들입니다. 주로 과거 시제로 기록합니다. (e.g. 로그인에 성공함, 상품이 배송됨)
Command: Domain Event를 유발시키는 명령입니다. 주로 API와 대응. 일대일 대응은 아님.
Policy: 도메인 내의 규칙으로, Domain Event뒤에 따라오는 하나의 비즈니스 로직이라고 보시면 됩니다. Policy에 의해 다른 Event가 Trigger될 수 있다. (e.g. 매월 카드 결제일이 되면 계좌에서 결제대금이 빠져나간다.)
External System: 이메일 전송 시스템, 결제 시스템과 같은 외부 시스템입니다. 외부 시스템에 의해 Event가 트리거 되기도 한다.
Hotspot: 의문 혹은 질문, 미결정 사항.
Aggregate: 비즈니스 로직 수행을 위한 데이터 객체의 집합. (e.g. 주문이라는 agreegate는 배송정보, 결제정보와 같은 Domain Model(Entity)로 이루어져 있습니다.) 정의하기가 어렵다. 하지만, Aggregate를 정의함으로써, 모델간의 경계를 잘 정의 할 수 있고, 코드의 일관성을 유지할 수 있습니다. 도메인이 복잡할 때 더욱 필요.
Bounded Context: Actor, Domain Event, Command를 고려한 하나의 집합. (e.g. 쇼핑몰을 예로 들면, 회원 가입, 정보 수정등을 담당하는 회원 Context, 상품의 주문 및 결제를 담당하는 상품 Context, 배송을 담당하는 배송 Context가 있다.) Bounded Context는 복잡한 비즈니스 도메인에서 이를 구분하고, 관리하기 위해 사용되며 각 컨텍스트 별로 담당하는 조직이 나뉘기도 합니다. 또한, Architecture로 분리되기도.
REST란?
http를 이용한다.
- URI(Resource) - 먼저 URI 를 통해 Reousrce 이름을 표현. /models 이런식.
- Method(Verb) - HTTP의 Method를 사용, GET, POST, PUT, PATCH, DELETE, OPTIONS이 있음.
options: 서버와 클라이언트 사이의 통신 옵션을 확인하기 위해 사용. 이게 문제가 있으면 내가 실수한게 아니라 통신 문제란걸 알수있음
- GET : Read 요청
- POST : Create 요청. 새로운 Resource를 생성하기 위해 사용합니다.
- PUT : Update 요청. Resource에 대한 정보를 수정하기 위해 사용합니다. 수정되는 정보를 포함한 모든 Resource의 정보를 포함하여 요청. 즉, 전부다 수정.
- PATCH : Update 요청다. Resource에 대한 정보를 수정하기 위해 사용합니다. 수정되는 정보만을 요청합니다.
- DELETE : Delete 요청입니다.
URI, 즉 Resource의 이름은 명사, 소문자, 복수형을 사용하길 권장합니다. /posts 이런식으로요! /getPosts 이런식으로 동사를 사용하는걸 지양
/ 를 통해 Resource 관의 계층 관계를 표현. 예를 들어 특정 포스트에 달린 댓글들을 URI로 표현한다면, /posts/{id}/comments
URI 마지막에 / 를 포함하지 않는다. /posts/ 이런 형태는 지양
밑줄 (_)은 사용하지 않아야하고, 가독성을 높이려면 하이픈(-)을 사용.
/posts/{id}/long-comments 이런식
Resource 하나를 가져올때에는 URI에 해당 Resource의 Identifier를 포함하여 표현. /posts/{id}
Resource 목록의 페이징(Paging), 필터링(Filtering), 정렬(Sorting), 검색(Searching)을 통해 정보를 가져올시, Path Variable을 활용. /posts?page=12 , /posts?order=latest 이런식
페이징: 페이지1,2,3처럼 쪼개서 가져오는 것
필터링: 남자 20대 이렇게 필터링해서 쪼개서 가져옴
정렬: 가격순 정렬 이런거 검색은 말 그대로
paging 1 & Filtering ~ & 이렇게 &로 여러 개 가능
- 자주 쓰는 상태 코드
- 글 목록의 조회: GET /posts
- 단일 글 조회: GET /posts/{id}
- 글 생성: POST /posts
- 글 수정: PUT /posts/{id}
- 글 삭제: DELETE /posts/{id}
- 특정 글의 댓글 목록 조회: GET /posts/{id}/comments
- 특정 글에 댓글 추가 : POST /posts/{id}/comments
- 특정 글의 댓글 수정: PUT /posts/{id}/comments/{id}
- 특정 글의 댓글 삭제: DELETE /posts/{id}/comments/{id}
이제 이것들을 바탕으로 API를 만들면,
이중 회원가입에서 로그아웃까진 중요하니까 이 형태를 잊지말 것.
그리고 대부분은 200이지만, post는 생성이라서 생성을 뜻하는 201이고 삭제는 204임을 기억할 것.
API설계는 보통 Postman 과 Swagger를 씀 우리는 Swagger 씀.
스웨거 적용법: 인텔리제이 들어가서 파일명 찾기. (쉬프트 컨트롤 n) build.gradle를 찾은 뒤 dependencies 항목에 아래 라인을 추가.
implementation("org.springdoc:springdoc-openapi-starter-webmvc-ui:2.2.0")
실행 완료 후 http://localhost:8080/swagger-ui/index.html
근데
Whitelabel Error Page
This application has no explicit mapping for /error, so you are seeing this as a fallback.
Mon Dec 18 17:07:46 KST 2023
There was an unexpected error (type=Not Found, status=404).
이런 에러가 계속 떠서 디버그도 돌리고 상담까지 받아본 결과, 삭제하고 재설치 했더니 됬다!! 왜 안됬던걸까? 하지만 이것은 착각에 불과했으니...
어쨌든 다시 돌아와서, 생성된 api의 이름은 OpenAPI definition인데, 이걸 바꾸고 싶다면,infra라는 이름의 패키지를 생성하고 거기에 또 스웨거라는 패키지를 생산한다. 그러면 infra.swagger으로 보이게 된다.
그리고 거기에 SwaggerConfig 클래스를 만든다. 그리고 거기에 이것을 붙여넣는다.
import io.swagger.v3.oas.models.Components
import io.swagger.v3.oas.models.OpenAPI
import io.swagger.v3.oas.models.info.Info
import org.springframework.context.annotation.Bean
import org.springframework.context.annotation.Configuration
@Configuration
class SwaggerConfig {
@Bean
fun openAPI(): OpenAPI = OpenAPI()
.components(Components())
.info(
Info()
.title("Course API")
.description("Course API schema")
.version("1.0.0")
)
}
근데 또 에러뜬다… 죽고싶다…
이젠 실행 자체가 안된다. 그 전엔 멀쩡히 실행되던 놈들이 왜??? 왜????
그렇게 몇시간을 헤맨 결과? 광명이 보인 것 같다. 다시 처음부터 프로젝트를 짜올린 결과,
이 망할 돌팔이 프로그램이 멋대로 멀쩡한 놈을 오타로 지정해서 그런거라는 결론이 나왔다.
난 오타라니까 시키는대로 바꿨는데, 오타가 아닌걸 바꿨으니 작동이 안되지!!!!
드디어!!!! 제목이 Course API로 바꼇어!!!!!!!!!
몇시간을 버렸지????? 아까운 내 시간!!!!!