글쓰는 감자

TDD(Test-Driven Development, 테스트 주도 개발)

• fail → test pass → refactoring의 사이클을 반복
• 기능별로 구현이 이루어지기 때문에 유지보수/디버깅이 쉽고, 기능별 모듈화에 좋다.

fail : 지금 구현하고자 하는 기능에 실패하는 테스트 코드를 작성

pass : 실패하는 테스트 코드가 통과하는 제대로 된 코드를 작성

Unit Test

• 기능(method)을 테스트하는 method(TDD의 fail단계)
• 프로그램 전체를 실행시킬 필요가 없이 테스트 코드로 확인이 가능!
• 버그를 줄이고, 코드의 퀄리티를 높인다.

❗ 이 테스트에 익숙해지면 디버깅을 큰 틀(기능 단위)로 잡아서 하는 것처럼 쉽게 할 수 있을 것 같다...

(아직 디버깅이나 이런 테스트에 취약하다.. 열심히 공부해보자!) ❗

Spring Security

Spring기반의 애플리케이션의 보안(인증과 권한, 인가 등)을 담당하는 스프링 하위 프레임 워크

'인증'과 '권한'에 대한 부분을 Filter 흐름에 따라 처리

Authorization(인증)과 Authentication(인가)

인증: 해당 사용자가 본인이 맞는지를 확인하는 절차

인가: 인증된 사용자가 요청한 자원에 접근 가능한지를 결정하는 절차

" 인증 성공 후 인가"

Principal(접근주체, 아이디): 보호받는 Resource에 접근하는 대상

Credential(비밀번호): Resource에 접근하는 대상의 비밀번호

" Credential 기반의 인증방식"

주요 모듈

[SecurityContextHolder] : 보안 주체의 세부 정보를 포함하여 응용프로그램의 현재 보안 컨텍스트에 대한 세부 정보가 저장된다.

[SecurityContext] : Authentication을 보관하는 역할

[Authentication] : 현재 접근하는 주체의 정보와 권한을 담는 인터페이스

[UsernamePasswordAuthenticationToken] : Authentication을 implements한 AbstractAuthenticationToken의 하위 클래스(user의 id = principal, password = credential)

[AuthenticationProvider] : 실제 인증에 대한 부분을 처리

[Authentication Manager] : 인증에 대한 부분을 처리

[UserDetails] : 인증에 성공하여 생성된 객체, UsernamePasswordAuthenticationToken을 생성하기위해 사용

[UserDetailsService] : UserDetails 객체를 반환(DB와 연결해 처리)

[Password Encoding] : 패스워드 암호화에 사용될 PasswordEncoder 정의

[GrantedAuthority] : 현재 사용자(principal)가 가지고 있는 권한(ROLE_ADMIN)

참고) https://mangkyu.tistory.com/76

Spring 실행 순서

1. web.xml을 로드하여 Servlet Container를 실행
2. Servlet Container는 web.xml을 읽어 등록된 ContextLoaderListener을 실행
3. ContextLoaderListener는 default 값으로 applicationContext.xml(root-context.xml) 파일을 읽어 Spring Container를 생성. 이를, Root Container라고도 부름.
4. Root Container에는 모든 Servlet과 Filter들이 공유하는 자원을 메모리에 생성(Service, DB connection, DAO 등)
   5-6. Client로부터 요청이 들어오면 Servlet Container는 Dispatcher Servlet을 생성
5. Dispatcher Servlet는 presentation-layer.xml(servlet-context.xml) 파일을 읽어 새로운 Spring Container를 생성. 여기서 생성된 컨테이너는 Controller 객체를 메모리에 생성

Client 접근 동작 순서

1-2. Client가 WAS에 접근하면 FrontController 역할을 하는 DispatcherServlet이 요청을 가로챔
3. HandlerMapping 설정에서 해당 요청을 처리할 Controller를 탐색
4. Controller에서 RequestResponseBodyMethodProcessor가 presentation-layer.xml(servlet-context.xml)에 선언해놓은 MessageConverter을 이용하여 요청 본문(파라미터) 읽음

5-10. 데이터 저장 및 응답 가공
11. 요청을 처리한 뒤, HTML로 응답할 경우 결과를 출력할 View의 이름, Data로 응답할 경우 MessageConverter을 이용하여 Json 데이터를 반환
12. HTML로 응답한 경우 ViewResolver에서 받은 view 이름(string)으로부터 해당 view를 탐색
13. 탐색한 view 객체를 반환
14. 처리 결과가 포함된 View를 DispatcherServlet에 전달
15. Client에게 최종 결과 출력

URI

"Uniform Resource Identifier" (통합 자원 식별자)

URL

컴퓨터 네트워크 상에서 리소스가 어디 있는지 알려주기 위한 규약(URI의 서브셋)

"URI는 식별하고 URL은 위치를 가리킨다"

"웹 개발은 크게 프론트엔드 개발과 백엔드 개발로 나눌 수 있다"

Front -End 

• 유저와의 상호작용이 일어나는 인터페이스 전체를 개발
• 주로 사용하는 언어 : HTML, CSS, JavaScript

Back-End

• 유저에게 보이지 않는 튼튼한 서버와 인프라 구축
• UX엔지니어, SRE, DevOps 등으로 세분화

• UX(User Experience) Engineer : 사용자 경험 개선 또는 새로운 경험 제공의 목적으로 디자인 아이디어를 프로토타입으로 만드는 전문 엔지니어
• SRE(Site Reliability Engineering) : IT운영에 대한 소프르웨어 엔지니어링 접근 방식, 소프트웨어를 툴로 활용하여 시스템을 관리하고 문제를 해결하며 운영 태스크를 자동화
• DevOps(development + operations) : 하나의 아이디어가 사용자에게 가치를 제공할 수 있도록 운영 환경에서 개발로부터 배포로 진행되는 프로세스의 속도를 높이는 접근 방식(코딩에서 배포, 유지관리 및 업데이트에 이르는 개발 사이클 전체에 걸쳐 요구 사항간의 균형을 맞춘다)

SRE vs DevOps

" 조직의 생산 운영 관리, 모니터링/식별 가능, 자동화"

주요 차이점

❗내가 조금 더 관심이 가는 분야는 BE이며 SRE나 DevOps가 궁금하다❗

REST

"Representational State Transfer"

• 자원을 이름으로 구분하여 해당 자원의 상태를 주고 받는 모든 것을 의미
• 자원(resource)의 표현(representation)에 의한 상태 전달
  • 자원: 소프트웨어가 관리하는 모든 것(문서, 그림 등)
  • 자원의 표현: 자원을 표현하기 위한 이름(DB의 학생정보가 자원이면 'students'는 자원의 표현
  • 상태 전달: JSON 혹은 XML을 통해 데이터를 주고 받는다
• HTTP URI(Uniform Resource Identifier)를 통해 자원(Resource)을 명시하고, HTTP Method(POST, GET, PUT, DELETE)를 통해 해당 자원에 대한 CRUD Operation을 적용하는 것을 의미한다.
• 필요한 이유
  • 애플리케이션 분리 및 통합
  • 다양한 클라이언트의 등장
  • 최근의 서버프로그램은 다양한 브라우저와 안드로이드폰, 아이폰과 같은 모바일 디바이스에서도 통신을 할 수 있어야한다.
• 구성요소
  • 자원(Resource): URI
  • 행위(Verb): HTTP Method
  • 표현(Representation of Resource): JSON, XML, TEXT, RSS
• 특징
  • Server-Client: 서로간 의존성이 줄어든다.
  • Stateless: Client의 context(세션, 쿠키..)를 Server에 저장하지 않는다.
  • Cacheable: 웹 표준 HTTP 프로토콜을 그대로 사용하므로 웹에서 사용하는 기존의 인프라를 그대로 활용 가능
  • Layered System
  • Code-On-Demand: Server로부터 스크립트를 받아 Client에서 실행한다.(Optional)
  • Uniform Interface: URI로 지정한 Resource에 대한 조작을 통일되고 한정적인 인터페이스로 수행한다.

REST API

• REST 기반으로 서비스 API를 구현한 것(API: Application Programming Interface)
• 특징
  • 사내 시스템들도 REST 기반으로 시스템을 분산해 확장성과 재사용성을 높여 유지보수 및 운용을 편리하게 할 수 있다.
  • REST는 HTTP 표준을 기반으로 구현하므로, HTTP를 지원하는 프로그램 언어로 클라이언트, 서버를 구현할 수 있다.

❗ REST API 설계 규칙에 관해서는 https://gmlwjd9405.github.io/2018/09/21/rest-and-restful.html 를 확인하자 ❗

RESTful

• 일반적으로 REST라는 아키텍처를 구현하는 웹 서비스를 나타내기 위해 사용되는 용어
• "REST 원리를 따르는 시스템을 지칭"
• 목적
  • 이해하기 쉽고 사용하기 쉬운 REST API를 만드는 것
  • 일관적인 컨벤션을 통한 API의 이해도 및 호환성을 높이는 것
  • 성능이 중요한 상황에선 굳이 RESTful한 API를 구현할 필욘 없다!

❗ 아마 url, uri와 관련이 깊은 것으로 생각된다.. 다음 내용으론 url과 uri의 차이를 알아봐야겠다 ❗