개인과제

이수형·2022년 9월 1일
0
🔐 Q1. API란 무엇인가?
  • API (Application Programming Interface)

API는 '애플리케이션 프로그래밍 인터페이스(Application Programing Interface)의 약자로, 프로그램과 프로그램이 서로 데이터를 주고받기 위해 사전에 정한 요청∙응답 방식을 말한다.

즉, 프로그램들이 서로 상호작용하는 것을 도와주는 매개체 역할을 한다.

🔐 Q2. Client와 Sever란 무엇인가?
  • 클라이언트(Client)

클라이언트는 일반적인 웹 사용자의 인터넷이 연결된 장치들과 이런 장치들에서 이용 가능한 웹 브라우저(웹 클라이언트)에 접근하여 서버에 요청하는 소프트웨어입니다. 클라이언트측에서는 Java Applet, Java Script, HTML, Active-X Control 등의 기술이 사용됩니다.

  • 서버(Server)

웹 어플리케이션에서의 모든 자원은 Server에 집중됩니다. 서버에서 일차 수행되면서 서버의 자원을 화용하고, 그 결과를 서버로부터 클라이언트 장치에 제공하게 됩니다. 서버측에서는 ASP, 미들웨어(PHP), 데이터베이스(MySQL), CGI 등의 기술이 사용됩니다.

🔐 Q3. WAS란 무엇인가? Web Server와 차이점은 무엇인가?

WAS(Web Application Server)란?

  • DB 조회나 로직 처리를 요구하는 동적 컨텐츠를 제공하기 위해 만들어진 Web Application Server이다
  • Web container, Servlet Container 라고도 불린다.
  • container란 jsp, servlet을 실행시킬 수 있는 소프트웨어를 말한다

*jsp(Java Server Page)

개념

  • java 코드가 들어있는 html 코드

특징

  • 서블릿은 자바 소스 코드 속에 HTML코드가 들어가 있는 형태인데, JSP는 이와 반대로 HTML 소스코드 속에 자바 소스코드가 들어가는 구조
    를 갖는 웹 어플리케이션 프로그래밍 기술이다.
  • JSP 는 WAS(Web Application Server)에 의하여 서블릿 클래스로 변환되어 사용된다.

*servlet

개념

  1. 동적 웹페이지를 만들 때 요청(request)과 응답(response)의 흐름을 간단한 메서드 호출만으로 체계적으로 다룰 수 있게 해주는 java기반의 웹 프로그래밍 기술
  2. 클라이언트의 요청을 처리하고, 그 결과를 반환하는 servlet 클래스의 구현 규칙을 지킨 자바 웹 프로그래밍 기술
  3. 자바를 사용하여 웹을 만들기 위해 필요한 기술

특징

  1. html을 사용하여 요청에 응답
  2. java thread를 이용하여 동작
  3. MVC 패턴에서 Controller로 이용
  4. HTTP 프로토콜 서비스를 지원하는 javax.servlet.http.HttpServlet 클래스를 상속받음

WAS의 종류와 특징

Tomcat 기능

  • jsp/servlet container 중 하나로 사용자에게 jsp요청을 받으면 서블릿으로 바꾸어 실행
  • Web Server에서 요청한 동적 페이지를 읽어 프로그램을 실행
  • 그 결과를 다시 HTML로 재구성하여 Web server에 전달

Tomcat 특징

  • servlet container를 지원함
  • 톰캣은 실제로 웹 서버와 통신하며 JSP와 Servlet이 작동하는 환경을 제공해줌
  • os의 제약이 없음(windows, linux, unix 등)

Web server와 WAS는 목적이 다르다.

웹 서버는 정적인 데이터를 처리하는 서버이다. 이미지나 단순 html 파일과 같은 리소스를 제공하는 웹 서버를 통하면 was를 이용하는 것보다 빠르고 안정적이다.

WAS는 동적인 데이터를 처리하는 서버이다. DB와 연결되어 데이터를 주고 받거나 프로그램으로 데이터 조작이 필요한 경우에는 WAS를 활용해야 한다.

🔐 Q4. HTTP 프로토콜이란 무엇인가?

HTTP 프로토콜이란?

HTTP(Hypertext Transfer Protocol) 프로토콜이란 상호 간에 정의한 규칙을 의미하며 특정 기기 간에 데이터를 주고받기 위해 정의다.

웹에서는 브라우저와 서버 간에 데이터를 주고받기 위한 방식으로 HTTP 프로토콜을 사용하고 있습니다.

HTTP 프로토콜의 특징

  • 클라이언트 서버 구조
    • 클라이언트가 서버에 요청을 보내고 응답을 받는 Request, Response 구조
  • 무상태 프로토콜(Stateless)
    • 서버가 클라이언트의 상태를 보존하지 않음
  • 비연결성(Connectionless)
    • Request, Response 가 종료되면 연결을 끊는 비연결성 모델
    • 서버 자원을 효율적으로 사용 가능
🔐 Q5. Restful API는 무엇인가?
  • REST(Representational State Transfer) 원리를 따르는 API
  • 두 컴퓨터 시스템이 인터넷을 통해 정보를 안전하게 교환하기 위해 사용하는 인터페이스
  • 웹의 장점을 최대한 활용
  • HTTP Method별로 역할 명시
  • 서버 응답 시간을 개선하기 위해 클라이언트 또는 중개자에게 일부 응답을 저장하는 프로세스인 캐싱을 지원
  • 서버는 소프트웨어 프로그래밍 코드를 클라이언트에게 전송해 클라이언트 기능을 일시적으로 확장하거나 사용자 지정 가능
  • 균일한 인터페이스

-균일한 리소스 식별자 사용해 요청이 리소스를 식별하도록 함

-서버는 리소스를 자세히 설명하는 메타데이터를 전송해 클라이언트가 리소스를 수정하거나 삭제하기에 충분한 정보를 갖게 도움

-서버는 클라이언트가 리소스를 적절하게 사용할 수 있는 방법에 대한 메타데이터가 포함된 명확한 메시지를 전송해 클라이언트는 표현을 추가로 처리하는 방법에 대한 정보를 수신

-서버는 클라이언트가 더 많은 리소스를 동적으로 검색할 수 있도록 표현에 하이퍼링크를 넣어 전송해 클라이언트는 작업을 완료하는 데 필요한 다른 모든 관련 리소스에 대한 정보를 수신

  • 무상태

-서버가 이전의 모든 요청과 독립적으로 모든 클라이언트 요청을 완료

-클라이언트는 임의의 순서로 리소스 요청 가능

-모든 요청은 무상태이거나 다른 요청과 분리됨

  • 계층화 시스템

-클라이언트는 클라이언트와 서버 사이의 다른 승인된 중개자에게 연결할 수 있으며 서버로부터도 응답을 받음

-서버는 요청을 다른 서버로 전달 가능

  • 확장성

-클라이언트와 서버 상호 작용을 최적화

-서버가 과거 클라이언트 요청 정보를 유지할 필요가 없기 때문에 서버 로드 제거

  • 유연성

-완전한 클라이언트-서버 분리 지원

-각 부분이 독립적으로 발전할 수 있도록 다양한 서버 구성 요소를 단순화하고 분리

  • 독립성

-API 설계에 영향을 주지 않고 다양한 프로그래밍 언어로 클라이언트 및 서버 애플리케이션을 모두 작성

-통신에 영향을 주지 않고 양쪽의 기본 기술을 변경

  • 작동 방식

-클라이언트는 API 문서에 따라 서버가 이해하는 방식으로 요청 형식을 지정해 서버에 요청 전송

-서버가 클라이언트를 인증하고 해당 요청을 수행할 수 있는 권한이 클라이언트에 있는지 확인

-서버가 요청을 수신하고 내부적으로 처리

-서버가 클라이언트에 응답을 반환. 요청이 성공했는지의 여부를 클라이언트에 알려주는 정보 제공. 클라이언트가 요청한 모든 정보 반환.

DIY Section

🔑 Q1. 객체지향 설계 5원칙 SOLID

SOLID는 객체지향 설계 5원칙의 앞 머리 알파벳을 따서 부르는 이름이다. 이 원칙들은 응집도를 높이고, 결합도를 낮추라는 고전원칙을 객체지향의 관점에서 재정립한 것이라고 할 수 있다. SOLID는 객체 지향 프로그램을 구성하는 속성, 메서드, 클래스, 객체, 아키텍처 등 다양한 곳에 다양하게 적용되는 것이기에 막상 적용되었는지 애매모호하거나 사람의 관점에 따라 다르게 해석될 수 있는 소지가 있다. SOLID자체가 제품이 아닌 개념이기에 그렇다.

SOLID는 객체지향 4대 특성을 발판으로 디자인 패턴의 뼈대이며 스프링 프레임워크의 근간이다.

1.SRP

Single Responsibility Principle의 두 문자로 단일 책임 원칙을 의미한다. 소프트웨어의 한 객체는 단하나의 책임만을 가질 수 있다. 변경을 해야할때 파급효과가 적다면 하나의 책임을 가지고 있는 것이라 말할 수 있다. 즉 객체간의 응집도를 최대화하고, 객체간의 결합도를 최소화 하는 것이 좋은 프로그램이라 볼 수 있다.

남자라는 클래스 하나만 있으면 남자클래스가 혼자 해야할 일과 책임이 너무 많게된다. 객체지향에서는 이런것을 나쁜냄새가 난다고 보고 이것을 각 역할에 맞게 분리하라는 것이 바로 SRP 단일 책임 원칙이다.

2.OCP

Open/Closed principle의 두 문자로 개방 폐쇄 원칙이다. 소프트웨어가 기존 코드를 변경하지 않고(Close) 확장할 수 있다(Open) 확장에는 열려있고 변경에는 닫혀있야한다. 바꿔 말하면 자신의 확장에는 열려있고 주변의 변화에 대해서는 닫혀있어야 한다는 말이다.

편의점에서 일일 삼교대로 직원이 교대한다고 할때 직원이 바뀐다고해도 손님이 구매하는데 영향이 없다. 또한 직원이 여자, 남자, 어른, 아이, 사장 등이라고 해서 이 또한 손님의 구매하는 행위는 영향을 받지않는다. 직원교대라는 주변의 변화에 손님의 구매행위는 영향을 받지않는 것이 주변의 변화에 닫혀있는 것이고, 직원은 교대라는 확장에 열려있다고 할 수 있다. 교대 이외에도 구매 담당자의 행위를 추가하거나, 보안 담당자의 행위를 추가하는 확장에 대해 직원은 열려있다.

개방 폐쇄 원칙을 따르지 않아도 OOP를 구현할 수 있지만 OOP의 장점인 유연성, 재사용성, 유지보수성을 얻을 수 없다.

3.LSP

Liskov Substitution Principle의 두 문자로 리스코프 치환 원칙이다. 하위 클래스의 인스턴스는 상위형 객체 참조 변수에 대입해 상위 클래스의 인스턴스 역할을하는데 문제가 없어야 한다는 내용이다.

  • 하위 클래스 is a kind of 상위 클래스 - 하위 분류는 상위 분류의 한 종류다
  • 구현 클래스 is able to 인터페이스 - 구현 분류는 인터페이스 할 수 있어야 한다.

위 두개의 문장대로 구현되었으면 LSP를 잘지켰다고 할 수 있다.

위 그림은 계층도/조직도로 LSP 위반 사례이다. 딸은 아버지, 할아버지의 역할을 할 수 없다.

위 그림은 분류도로 LSP적용 사례이다. 고래는 포유류, 동물로서의 역할을 하는 것이 전혀 문제가 되지 않는다.

4.ISP

Interface Segregation Principle의 두 문자로 인터페이스 분리 원칙이다. 클라이언트는 자신이 사용하지 않는 메서드에 의존관계를 맺으면 안된다는 내용이다.

위 SRP에서 남자클래스의 과중한 업무를 남자 클래스를 토막내어 남자친구, 사원, 아들, 소대원으로 클래스를 나눠서 분담했다면 인터페이스 분리 원칙에서는 남자클래스는 그대로이고 다중인격화(?)시켜 여자친구를 만날때 남자친구 역할만, 어머니와 있을때 아들 역할을 할 수 있도록 인터페이스를 나눈다.

결론적으로 같은 문제에 다른 해결방법이라고 볼 수 있는데, 특별한 경우가 아니라면 단일 책임 원칙을 적용하는 것이 더 좋은 해결방법이다. 인터페이스를 통해 메서드를 외부에 제공할 때는 최소한의 메서드만 제공하라는 인터페이스 최소화주의 원칙때문이다.

5.DIP

Dependency Inversion Principle의 두 문자로 의존 관계 역전 원칙이다. 고차원 모듈은 저차원 모듈에 의존하면 안되고 두 모듈은 모두 다른 추상화 된 것에 의존해야한다. 추상화된 것은 구체적인 것에 의존하면 안되고 구체적인 것이 추상화된 것에 의존해야한다. 결론은 구현체보다 추상 클래스에 의존해야한다는 원칙입니다.

자동차는 스노어 타이어에 의존한다. 자동차는 한번 타면 오래 타는데 스노우 타이어는 겨울이 지나며 일반타이어로 교체해야한다. 이런 경우 자동차 클래스가 자주변경되는 구현체 클래스에 의존하고 있다고 말할 수 있다.

자동차가 구체적인 타이어(스노우,일반,광폭타이어)가 아닌 추상화된 타이어 인터페이스에만 의존하게 함으로써 스노우타이어에서 일반으로, 다른 구체적인 타이어로 변겅되어도 자동차는 이제 그 영향을 받지않는 형태로 구성된다. 스노우타이어는 원래 무엇에도 의존하지 않는 타이어 였는데 추상적인 타이어 인터페이스에 의존하게 되었다. 바로 의존의 방향이 역전된 것이다. 자동차는 자신보다 변하기 쉬운 스노우 타이어에 의존하던 관계를 중간에 추상화된 타이어 인터페이스를 추가해 두고 의존 관계를 역전시켰다. 이처럼 자신보다 변하기 쉬운것에 의존하던것을 추상화된 인터페이스나 상위 클래스를 두어 변하기 쉬운 것의 변화에 영향받지 않게 하는 것이 의존 역전 원칙이다.

🔑 Q2. Error와 Exception

Error

시스템에 비정상적인 상황이 생겼을 때 발생한다.

시스템이 종료되어야 할 수준의 심각한 문제이다. 예측하여 방지할 수 없다.

Exception

개발자가 구현한 로직에서 개발자의 실수 혹은 사용자의 영향으로 발생한다.

미리 예측하여 처리할 수 있어 상황에 맞는 예외처리를 통해 프로그램이 종료되지 않고

정상적으로 작동하게 할 수 있다.

  • NullPointerException : 객체가 필요한 경우인데 응용프로그램이 null을 사용하려고 시도할 경우 발생
  • IllegalArgumentException : 메서드가 허가되지 않거나 부적절한 argument를 받았을 때 발생
  • ArrayIndexOutOfBoundsExcetion : 배열의 범위를 벗어난 index를 접근할 시 발생
  • IOException : 입출력 동작 실패 또는 인터럽트 시 발생

*인터럽트 : 우선적으로 처리해야할 일이 발생하였을 때 그것을 처리하고 원래 동작으로 돌아옴

🔑 Q3. Dispatcher Servlet 이란?

Dispatcher Servlet 이란?

Dispatcher Servlet에서 dispatch는 "보내다" 라는 사전적 의미를 가지고 있습니다.본격적으로 Dispatcher Servlet에 대해 설명하기 앞서 FrontController 패턴의 개념을 살펴보고 가겠습니다.1. FrontController 패턴 이란?

우리는 사용자의 요청을 Servlet에게 전달하기 위해 web.xml 에 servlet을 등록하고 mapping하는 과정이 필요합니다. 하지만 수 많은 요청이 필요한 경우 계속해서 이 작업을 필요로 하기 때문에 이 점을 해소하고자 FrontController 패턴이 생겨났습니다.

Front Controller 패턴

Front Controller는 주로 서블릿 컨테이너의 제일 앞에서 서버로 들어오는 클라이언트의 모든 요청을 받아서

처리해주는 컨트롤러이며, MVC 구조에서 함께 사용되는 패턴이다.

1.1 기존의 Servlet

기존의 방식은 요청 url당 servlet을 생성하고 해당 Controller에게 요청을 보내는 코드를 따로 작성해야 했습니다.


1.2 Front Controller 패턴 적용

위 구조와 같이 FrontController 패턴을 적용하게 되면 하나의 Servlet에서 요청을 받아들여 적절한 Controller로 요청을 위임합니다.이렇게 FrontController 패턴을 적용하면 한 곳에서 모든 사용자의 요청을 컨트롤할 수 있기 때문에 기본적으로 사용자의 모든 요청에 대해 인코딩처리, 에러페이지 처리, 공지 등에 대한 처리를 한 곳에서 처리할 수 있습니다.


  1. Dispatcher Servlet위에서 설명한 FrontController 패턴을 취하는 구조를 Spring Framework에서는 Dispatcher Servlet이라는 것으로 만들어 두었습니다.

2.1 Dispatcher Servlet 의 역할

모든 요청을 한 곳에서 받아서 필요한 처리를 한 뒤, 요청에 맞는 handler로 요청을 Dispatch하고, 해당 Handler의 실행 결과를 Http Response형태로 만드는 역할을 합니다.

2.2 Dispatcher Servlet의 흐름

위에서 Servlet 대신 Dispatcher Servlet이라는 Servlet이 사용자의 모든 요청을 받아 여러 작업을 거친 뒤 Controller에게 역할을 위임합니다.Spring은 유연하고 다양한 설계를 위해 이런 구조를 채택했고 개발자는 Dispatcher Servlet에 붙어있는 Handler Mapping, Handler Adapter 등을 설정하여 요청 받았을 때 어떻게 동작할 것인지 정해줄 수 있습니다. (web.xml)

[요청받았을 때 거치는 순서]

1. Handler Mapping - 요청받은 URL에 해당하는 Controller 검색 / 결정 역할

2. Handler Adapter - 결정된 Controller의 메서드 호출 역할

3. Controller, Service, Repository - DB 데이터 Model에 저장 및 view이름 결정하여 전달

4. View Resolver - 어떤 종류의 view(jsp, html 등)를 사용할 것인지 선택 & 사용할 view 선택 역할

🔑 Amazon S3란 무엇인가

Amazon S3는 Amazon Simple Storage Service의 약자이다.


Amazon S3 구조

S3에는 Bucket과 Object라는 단위가 있습니다. 객체(Object)는 데이터와 메타데이터를 구성하고 있는 저장 단위이며 버킷(Bucket)은 이러한 객체를 저장하고 관리하는 역할을 하는 것입니다. 버킷을 생성하면 Owner 권한을 부여받게 되어서 버킷 단위로 여러 가지 기능들을 제어할 수 있습니다.

한 계정 당 Bucket은 최대 100개까지 사용이 가능하고, Bucket의 소유권은 이전할 수 없기 때문에 주의해야 합니다. 객체는 하나 당 1Byte에서 최대 5TB까지 저장이 가능하며 저장할 수 있는 객체의 수는 제한이 없습니다.

AWS S3 특징

  • 제공하는 단순한 웹 서비스 인터페이스를 사용하여 웹에서 언제 어디서나 원하는 양의 데이터를 저장하고 검색할 수 있습니다.
  • 개발자는 Amazon이 자체 웹 사이트의 글로벌 네트워크 운영에 사용하는 것과 같은 높은 확장성과 신뢰성을 갖춘 빠르고 경제적인 데이터 스토리지 인프라에 액세스할 수 있습니다.
  • 단독 스토리지로도 사용할 수 있으며 EC2, EBS, Glacier와 같은 다른 AWS 서비스와도 함께 사용할 수 있어 클라우드 어플리케이션, 컨텐츠 배포, 백업 및 아카이빙, 재해 복구 및 빅데이터 분석을 포함한 다양한 사례에 알맞다.
  • S3의 버킷은 무한대의 객체를 저장할 수 있으므로 스토리지의 요구를 미리 추정하여 관리할 필요가 없어 확장/축소에 신경쓰지 않아도 된다.
  • HTTPS 프로토콜을 사용하여 SSL로 암호화된 엔드포인트를 통해 데이터를 안전하게 업로드/다운로드 할 수 있으며 상주 데이터를 자동으로 암호화 하고 AWS KMS를 통해 S3에서 사용자를 위해 키를 관리하게 하는 방법과 고유한 키를 제공하는 방법 중에서 키 관리 방법을 선택할 수 있는 기능을 제공한다.
  • 사용한 스토리지 만큼 요금이 청구되며 데이터 전송부분에서는 해당 리전 내에서는 데이터 송수신은 무료(다른 AWS 리전으로는 무료가 아니다!)이고 S3에서 인터넷으로 데이터를 송수신 시에도 가격이 매우 저렴하다. 요금에 대한 부분은 이곳에서 확인 할 수 있습니다.

RDS와 차이점

스토리지와 데이터베이스 둘 다 저장장치의 역할을 하지만 스토리지는 파일저장소이고

데이터베이스는 데이터를 저장한다.

🔑 Q5. 서블릿(servlet)이란?

클라이언트의 요청을 처리하고, 그 결과를 반환하는 Servlet 클래스의 구현 규칙을 지킨 자바 웹 프로그래밍 기술

자바를 사용하여 웹을 만들기 위해 필요한 기술이며 클라이언트가 어떠한 요청을 하면 그에 대한 결과를 다시 전송 해주는 역할을 한다. 클라이언트의 요청에 대해 동적으로 작동하는 웹 어플리케이션 컴포넌트이며 MVC에서 Controller로 사용된다.

profile
후회없는 오늘이, 후회없는 내일

0개의 댓글