윤이네

Spring Boot JSP & Thymeleaf

Ellie_yoon — Wed, 8 Jun 2022 16:08:48 +0900

View Tempate Engine: JSP 와 Thymeleaf

1. JSP 사용

Embedded Sevlet 컨테이너의 Spring Boot를 사용할 경우 jar 를 사용할 수 없기 때문에 war 방식을 선택해야 한다.

WAR(Web Archive) 는 웹 어플리케이션 압축 타입으로 Servlet(JSP) 관련 패키지들을 포함하고 있기 때문에 복잡하고 무거운 구조이다.

반면에 Spring Boot는 독립적이고 가벼운 실행을 목표로 하기 때문에 이 방법과는 맞지 않아서, JSP 사용을 권장하지 않는다. 그 대체 템플릿 엔진으로 나온 것이 바로 Thymeleaf

[JSP 사용방법 업데이트 예정]

2.Thymeleaf

: 템플릿 엔진으로서, 기존 HTML 코드와 구조를 변경하지 않고 덧붙이는 방식이 특징

- view와 관련된 설정들은 꼭 정해진 디렉토리에 위치해있어야 한다.

/src/main/resources/templates

- 필요한 dependency (maven 기준) - thymeleaf 만 추가해주었다.

Maven Repository : https://mvnrepository.com/

<dependency>
  <groupId>org.springframework.boot</groupId>
  <artifactId>spring-boot-starter-web</artifactId>
</dependency>

<dependency>
  <groupId>org.springframework.boot</groupId>
  <artifactId>spring-boot-starter-tomcat</artifactId>
  <scope>provided</scope>
</dependency>

<dependency>
  <groupId>org.springframework.boot</groupId>
  <artifactId>spring-boot-starter-thymeleaf</artifactId>
</dependency>

Thymeleaf 제공 Template

HTML
XML
TEXT
Javascript
Css
Raw

Thymeleaf 문법

- th:text="${변수명}"

<!--index.html-->
<html xmlns:th="http://www.thymeleaf.org">
<head>
    <meta charset="UTF-8">
    <title>title</title>
</head>
<body>
<!--/*@thymesVar id="name" type=""*/-->
<h1 th:text="${name}">Hello Thymeleaf</h1>
</body>
</html>

- th:href="@{변수명}"

: <a> 태그의 하이퍼링크 속성과 동일, 이동하고자 하는 페이지가 있을 때 사용

- th:with="${변수명}"

: 변수 형태의 값을 재정의하는 속성, 새 변수값 생성용

- th:value="${변수명}"

: input의 value에 값을 삽입할 때 사용, + 기호로 여러개의 값을 넣을 수 있음

Javascript에서 사용시

<html xmlns:th="http://www.thymeleaf.org">
<head>
    <script th:inline="javascript">
        /*<![CDATA[*/
        let data = /*[[${data}]]"*/;
        /*]]*/
    </script>
</head>
<body>
</body>
</html>

Controller 코드 예시

1. [Model] 사용 ver

@Controller
public class TempController {

    @GetMapping("/index")
    public String test(Model model){
        //속성 이름과 속성값 model에 추가 -> index.html 페이지에서 {$name} 으로 값을 읽음
        model.addAttribute("name","yoon");
        //리턴할 페이지 이름
        return "index";
    }
}

2. [ModelAndView] 사용 ver

@GetMapping("/test")
public ModelAndView test(HttpServletRequest request){
 	....
    ModelAndView mv = new ModelAndView();
    //리턴할 페이지 
    mv.setViewName("test");
    //리턴할 속성과 객체
    mv.addObject("request",request);

    return mv;
}

* Model 과 ModelAndView 차이

https://bestkingit.tistory.com/155

[Spring Boot] Model 과 ModelAndView 차이.

인터셉터에서 세션 처리를 하는 도중에 문제가 생겼다. 지금까지 Controller에서 Model을 이용하여 view에 넣어주었는데, HandlerInterceptor의 postHandle에는 ModelAndView를 이용하는 것이다..(확장하면 되지..

bestkingit.tistory.com

JAVA Azure Application Insights 설정

Ellie_yoon — Tue, 31 May 2022 13:18:38 +0900

1. 모니터링을 위해 JAVA에 Application Insights 연결하기

준비

1. testweb(Remote Host)에 jar 파일 대기 - /home/user/

2. https://docs.microsoft.com/ko-kr/azure/azure-monitor/app/java-in-process-agent 에서 applicationinsights-agent.jar 다운로드하기

3. Azure Portal 에서 모니터 -> 어플리케이션 인사이트 -> 만들기

4. 3번완료시 생성된 연결문자열 복사해두기

연결 문자열 - Azure Portal -> 어플리케이션 인사이트 -> 연결문자열에서 확인 가능

:InstrumentationKey=~~~~으로 시작.

터미널

$mkdir test // jar unzip할 디렉토리

$cd test // test 디렉토리 이동

$unzip '/path/to/user/jar' // test 디렉토리에서 jar 파일 unzip

$ls -al //unzip된 파일들 확인

프로젝트

1. spring boot application 에 'azure' 폴더 만들고 applicationinsights-agent.jar 파일 + applicationinsights.json + setting 용 xml 위치시키기

2. applicationinsights.json 파일에 "connectionString" 수정과 클라우드 역할(role) 인스턴스 이름 넣기

'connectionString' 이 부분에 아까 복사한 연결문자열을 넣어주면 된다

클라우드 역할 인스턴스 항목은 머신의 기본값이름으로 설정되기 때문에 json 파일 추가는 optional 하다. 하지만 이름ㅇ르 변경하고 싶다면 같은 json 파일 안에

이런 식으로 추가하면 된다. 보통 어플리케이션 이름으로 흔하게 설정한다.

3. jvm 인수 추가 - javaagent

intellij ru/debug configuration (windows: alt+shift+f10)

vm 옵션 추가 후, 필드에

javaagent:path/to/applicationinsights-agent-3.2.11.jar

추가

4. application run

-> log 에 다음과 같은 메세지가 기록됨

- ApplicationInsights Java Agent 3.2.11 started successfull

출처

https://docs.microsoft.com/ko-kr/azure/azure-monitor/app/java-in-process-agent

Azure Monitor: Application Insights Java - Azure Monitor

코드를 수정할 필요 없이 모든 환경에서 실행되는 Java 애플리케이션에 대한 애플리케이션 성능 모니터링입니다. 분산 추적 및 애플리케이션 맵.

docs.microsoft.com

2. Application Insights 라이브메트릭 설정

Application Insights의 라이브 메트릭은 applicationinsights.json 파일의 jmxMetrics 을 추가함으로써 Azure Portal 내에서 확인이 가능하다.

메트릭으로 확인해 보고싶은 항목을 objectname 으로 설정하여 라이브 메트릭에서 실시간으로 확인이 가능하다

라이브 메트릭 화면 예시는 아래와 같다

https://docs.microsoft.com/ko-kr/azure/azure-monitor/app/live-stream#get-started

출처 https://docs.microsoft.com/en-us/azure/azure-monitor/app/java-standalone-config

Configuration options - Azure Monitor Application Insights for Java - Azure Monitor

How to configure Azure Monitor Application Insights for Java

docs.microsoft.com

이 포스팅과 무관하지만 jar unzip 시 항목들

[참고] Spring boot 는 BOOT-INF , META-INF , org 로 크게 3가지로 구성되어 있다.

1) BOOT-INFO : 클래스 파일들과 의존성이 있는 jar 파일들로 구성

2) META-INFO : MANIFEST.MF(프로젝트 매니패스트 파일) pom.xml(메이븐 설정 파일)

3) org

MANIFEST.MT 기존의 Java Jar 같은 경우에 Main-Class가 실제 Main Method (public static void main)가 있는 클래스로 설정되지만 Spring Boot 에서는 org.springframework.boot.loader.JarLauncher 라는 클래스로 설정됨

이는 Spring Boot 내부에서 의존성 라이브러리들이 존재하는 BOOT-INFO 폴더에서 Jar 파일들을 실행하는 방식으로 이뤄진다는 뜻

org.springframework.boot.loader.jar.JarFile을 사용해서 내장 JAR를 읽음
org.springframework.boot.loader.Launcher를 사용해서 실행
출처 : https://seongmun-hong.github.io/springboot/Spring-boot-Spring-Boot-Principal

Spring Boot 구동 원리

Spring Boot 구동 원리 Spring boot 는 빌드를 진행하면 Jar File이 나오게 된다. 이 Jar File 하나로 독립적으로 실행이 가능하다. 어떻게 이...

Seongmun-Hong.github.io

Azure Application Insights

Ellie_yoon — Fri, 27 May 2022 18:13:42 +0900

Application Insights 작동 방법 : 앱에 SDK(작은 계측 패키지)를 설치하거나 Application Insights 에이전트를 사용

Azure Insights 요금 : 앱에 상당한 사용량이 될 때 까지 요금 부과 x

(https://azure.microsoft.com/pricing/details/application-insights/)

Application Insights 원격 분석 탐색 방법 / 기능

https://docs.microsoft.com/ko-kr/azure/azure-monitor/app/app-insights-overview

모니터링 항목

l 요청 속도, 응답 시간 및 실패율

l 외부 서비스로 종속성 횟수, 응답 시간 및 실패율

l 예외

l 사용자의 브라우저에서 보고된 페이지 보기 및 로드 성능

l 속도, 응답 시간 및 실패율을 포함하여 웹 페이지의 AJAX 호출

l 사용자 및 세션 수

l CPU, 메모리 및 네트워크 사용량과 같은 Windows 또는 Linux 서버 컴퓨터의 성능 카운터

l Docker 또는 Azure의 호스트 진단

l 앱의 진단 추적 로그를 통해 추적 이벤트와 요청의 상관 관계를 지정할 수 있습니다

l 판매된 항목과 같은 비즈니스 이벤트를 추적하는 클라이언트 또는 서버 코드의 사용자 지정 이벤트 및 메트릭

(앱 코드에 대한 업데이트를 방지하므로 이미 배포된 앱에 적합)

계측: 애플리케이션이 원격 분석을 캡처할 수 있도록 하는 것

1. 자동 계측 애플리케이션 모니터링(ApplicationInsightsAgent) = 런타임 모니터링

https://docs.microsoft.com/ko-kr/azure/azure-monitor/app/azure-vm-vmss-apps?tabs=Java

Azure Portal을 사용하는 것입니다. Azure Portal에서 애플리케이션 모니터링을 켜면 Application Insights로 애플리케이션이 자동으로 계측되며 코드를 변경할 필요가 없습니다.

권장 사항)

- Azure App Services의 경우 이 모니터링 수준을 최소한으로 사용하는 것이 좋으며,

특정 시나리오에 따라 수동 계측을 통한 고급 모니터링이 필요한지 여부를 평가할 수 있습니다.

- 클라이언트 쪽 모니터링을 사용하려면 Javascript SDK 를 애플리케이션에 수동으로 추가해야함

- 프로파일러 및 스냅샷 디버거는 Java 애플리케이션에 사용할 수 없습니다.

설정방법) https://docs.microsoft.com/ko-kr/azure/azure-monitor/app/azure-web-apps-java

1. App Service의 Azure 제어판에서 Application Insights를 선택한 다음 사용을 선택

2. 새 리소스를 만들도록 선택하거나 이 애플리케이션에 대한 기존 Application Insights 리소스를 선택

3. 사용할 리소스를 지정한 후 Java 에이전트를 구성할 수 있습니다. Java 에이전트를 구성하지 않으면 기본 구성이 적용됩니다 (수동- 전체 구성 집합을 사용할 수 있으며 유효한 json 파일을 붙여넣기) - https://docs.microsoft.com/ko-kr/azure/azure-monitor/app/java-standalone-config#an-example

2. Application Insights SDK를 설치하여 코드를 통해 애플리케이션을 수동으로 계측 (OpenTelemetry 기반)

사용 시나리오) 자동 계측 모니터링을 사용하여 기본적으로 캡처되지 않는 이벤트/종속성을 추적하기 위해 사용자 지정 API 호출을 수행해야 하는 경우 이 방법을 사용

ApplicationInsights Java Agent 사용

https://docs.microsoft.com/ko-kr/azure/azure-monitor/app/java-in-process-agent

https://wiki.sansae.net/display/PS/Application+Insights+of+SpringBoot+-+5mHandsOn

1. jar 파일 다운로드

- application에 jar 파일 위치 시키기 (jar, applicationinsights.json )

2. JVM 환경변수로 -javaagent:path/to/applicationinsights-agent-3.2.11.jar 추가 [Run/Debug Configuration]

3. Application Insights 문자열 설정 (= jar 파일로 Application Insights 리소스를 가리키는 두 가지 방법)

(1). 환경변수 설정

– (Console) APPLICATIONINSIGHTS_CONNECTION_STRING = <Copy connection string from Application Insights Resource Overview>

(2). Applicationisights.json 이라는 구성 파일 만들기

- 키는 Application Insights -> amass_api_dbweb 연결문자열 이름

- 파일은 applicationinsights-agent jar과 동일한 디렉터리에 배치돼야함

4. Application Insights 리소스에서 연결 문자열 찾기

5. 데이터 흐르는지 확인 [Auzre Portal – Application Insights 리소스 탭]

Applicationinsights.json 구성 옵션

· 클라우드 역할 이름

· 클라우드 역할 인스턴스

· 샘플링

· JMX 메트릭

· 사용자 지정 차원

· 원격 분석 프로세서(미리 보기)

· 자동 수집된 로깅

· 자동 수집된 마이크로미터 메트릭(Spring Boot Actuator 메트릭 포함)

· 하트비트

· HTTP 프록시 : 애플리케이션이 방화벽 뒤에 있고 Application Insights에 직접 연결할 수 없는 경우(Application Insights에서 사용하는 IP 주소 참조), HTTP 프록시를 사용하도록 Application Insights Java 3.x를 구성할 수 있습니다.

· 자체 진단

Applicationinsights.json 구성 옵션

· 클라우드 역할 이름

· 클라우드 역할 인스턴스

· 샘플링

· JMX 메트릭

· 사용자 지정 차원

· 원격 분석 프로세서(미리 보기)

· 자동 수집된 로깅

· 자동 수집된 마이크로미터 메트릭(Spring Boot Actuator 메트릭 포함)

· 하트비트

· 자체 진단

Applicationinsights.json 구성 파일 예제 (https://docs.microsoft.com/ko-kr/azure/azure-monitor/app/java-standalone-config#an-example)

Spring - AOP

Ellie_yoon — Fri, 7 Jan 2022 16:04:20 +0900

AOP (Aspect Oriented Programming)

관점지향 프로그램

- 스프링 어플리케이션은 대부분 특별한 경우를 제외하고는 MVC 웹 어플리케이션에서는 Web Layer, Business Layer, Data Layer로 정의

- Web Layer: REST API를 제공하며, Client 중심의 로직 적용

- Business Layer: 내부 정책에 따른 logic을 개발하며, 주로 해당 부분을 개발

- Data Layer: 데이터 베이스 및 외부와의 연동을 처리

횡단 관심

- Method Parameter Log - 메소드 실행 시 어떤값이 들어가고 리턴되는지 확인

- 실행시간 Log - 특정 메소드의 실행시간

- Parameter Encode : 메소드가 들어갈 때나 반환될 때 값을 변환시켜줌

주요 Annotation

@Aspect : 자바에서 널리 사용하는 AOP프레임워크에 포함되며, AOP를 정의하는 Class에 할당

@Pointcut : 기능을 어디에 적용시킬지, 메소드? Annotation?등 AOP를 적용시킬 지점을 설정

@Before : 메소드를 실행하기 이전

@After : 메소드가 성공적으로 실행 후, 예외가 발생되더라도 실행

@AfterReturning : 메소드 호출 성공 실행 시 (Not Throws)

@AfterThrowing : 메소드 호출 실패 예외 발생 (Throws)

@Around : Before/after 모두 제어

Spring - IoC/DI 란?

Ellie_yoon — Fri, 7 Jan 2022 13:58:02 +0900

저작자: PHẠM HUY HO&amp;Agrave;NG 이미지 출처 :&amp;nbsp;https://toidicodedao.com/2015/11/03/dependency-injection-va-inversion-of-control-phan-1-dinh-nghia/

DI (Dependency Injection): 의존성 주입

- 외부의 컨테이너(Spring Conainer)에서 객체를 생성한 후 의존성을 주입시키는 설계 패턴

- 스프링에서 객체는 Bean 으로 표현된다.

DI 사용의 장점

- 모듈 간의 결합도가 낮아져, 유연성이 높아짐 따라서 안정적인 테스트 가능 ( Mock 을 통해)

- *순환참조(Circular Reference) 제거

*순환참조(Circular Reference) : 참조하는 대상이 서로 몰려있어서 참조할 수 없게 되는 현상.

- 재사용이 높고, 코드 변경 및 확장의 영향이 적음 (추상화)

DI 사용 - 객체에 의존성을 주입시키는 방법

대표적으로 3가지 방법이 있다.

[세터 기반 의존성 주입, 생성자 기반 의존성 주입, 필드 기반 의존성 주입]

1) 세터 기반 의존성 주입

- setter()메소드에 @Autowired를 지정하여 객체에 대한 의존성을 주입한다.

*@Autowired 란?

- 자동연결 (Autowiring)을 뜻하며 스프링 DI에서 사용되는 어노테이션으로, 컨테이너에 빈을 자동으로 주입해준다(즉, @Autowired 가 붙은 필드에 자동적으로 의존성을 주입해줌).

- 변수, 생성자, Setter(), 일반 메소드에 적용가능하다

예시: StudentController.java 에 Student 객체를 setter()를 사용하여 의존성을 주입해보자

public class StudentController {
    private Student student; //의존성 주입 대상 필드

    //Setter 를 사용한 의존성 주입
    @Autowired
    public void setStudent(Student student){
        this.student = student;
    }
}

이 주입 방법은 순환 참조 및 결합도 (Coupling) 문제로 권장되지는 않는다.

2) 생성자 기반 의존성 주입

- 생성자에 @Autowired 애너테이션을 지정하여 객체에 의존성을 주입한다

- 세터기반의존성 주입에 비해 권장되는 방식이다.

예시: StudentController.java 에 Student 객체를 생성자를 사용하여 의존성을 주입해보자

public class StudentController {
    private Student student; //의존성 주입 대상 필드

    //생성자를 사용하여 의존성 주입
    @Autowired
    public StudentController(Student student){
        this.student = student;
    }
}

Lombok을 사용한다면 @RequiredArgsConstructor를 사용한다면 위와 같은 코드를 조금 더 간결하게 구현할 수 있다.

다만 의존성 주입 대상 필드는 꼭 final로 선언을 해주어야만 해당 필드를 가진 생성자가 만들어진다.

public class StudentController {
    private final Student student; //의존성 주입 대상 필드
}

3) 필드 기반 의존성 주입

단순히 필드에 @Autowired 를 붙여서 의존성을 주입하는 것

예시: StudentController.java 안에서 Student 객체(필드) 의존성을 주입해보자

public class StudentController {
    @Autowired
    private Student student; //의존성 주입 대상 필드
}

IoC(Inversion Of Control) : 제어의 역전

- 제어의 역전, 즉 제어권한이 뒤바뀌었다는 뜻 (권한이 개발자에서 프레임워크로)

- 예전 자바기반 어플리케이션은 개발자가 직접 자바 객체를 생성하고, 의존관계를 연결함 (제어권을 개발자가 가지고 있었음 => DI)

하지만, Servlet 과 EJB가 생겨나면서 객체의 생성/관리등의 제어권한이 외부의 컨테이너로 넘어가 뒤바뀌게 됨 (제어권을 컨테이너가 가지게됨) 이를 우리는 "제어의 역전", IoC라고 표현한다.

예시) 개발자가 직접 객체를 생성하는 코드

import BBB.BBB;

public class AAA {
    
    private BBB bbb;
    
    public AAA(){
        bbb = new BBB(); // AAA 객체안에서 BBB 라는 객체가 New 생성자로 직접생성됨
    }
}

기존에 객체를 생성했던 방법을 간단히 살펴보면, 위의 코드와 같이 객체 AAA안에서 BBB의 객체를 쓰려면 new BBB()로 직접 생성해야 했다(즉 개발자들이 직접 객체를 생성해서 사용해옴).

이 코드를 다시 해석하면 AAA 라는 객체는 BBB라는 객체를 사용(의존)하고 있는 것을 확인할 수 있는데, 이것을 IoC 의 형태로 바꿔서 쓰면 (의존성 주입) 다음과 같다.

예시) 컨테이너에 의한 객체를 사용하는 코드

import BBB.BBB;
import org.springframework.beans.factory.annotation.Autowired;

public class AAA {

    @Autowired
    private BBB bbb;

}

이 객체는 스프링 컨테이너에 의해 생성 및 관리되기 때문에 코드에서 직접 객체를 생성하지 않고 의존관계만 주입해주는 것을 확인할 수 있다. 이것을 우리는 제어가 역전되었다 (IoC) 라고 한다. 이를 간단하게 말하면,

'의존성을 주입해준다' = 외부(스프링 컨테이너)에서 객체의 레퍼런스(객체의 주소)를 전달하여 객체를 참조할 수 있게 한다.

따라서 스프링에서 객체가 만들어지고 실행되는 과정은 다음과 같다

객체 생성 -> 객체에 의존성 주입 (컨테이너에 의해 관리되어지는 객체) -> 의존성 주입된 객체의 메소드 호출

IoC와 DI의 차이점

DI는 IoC 모델을 구현하는 방식중에 하나고,

IoC(객체의 제어권한을 외부에서 관리)는 DI(외부에서 생성된 객체를 주입하는 것)를 통해 실현되는 것이라고 이해하면 될 것 같다. 큰 차이점은 없는 것으로 보인다.

References

https://velog.io/@gillog/Spring-DIDependency-Injection

https://junu0516.tistory.com/87

https://life-with-coding.tistory.com/433

Spring Boot 시작하기 1장 (Get API-@GetMapping)

Ellie_yoon — Fri, 7 Jan 2022 01:56:30 +0900

Spring 은 엔터프라이즈 애플리케이션 개발에 널리 사용되는 오픈 소스 경량 프레임워크이고, Spring Boot는 기존의 Spring 프레임워크 위에 구축되어 REST API 개발에 널리 사용되는 오픈 소스 마이크로 프레임워크이다.

Spring Boot 의 장점

- Spring 기반 어플리케이션의 빠르고 쉬운 개발

- war 파일의 배포가 필요 없음

- 독립 실행형 어플리케이션 (standalone application)

- Tomcat, Jetty, Undertow 같은 웹서버를 응용프로그램에 직접 내장할 수 있음

- XML을 구성할 필요가 없음

- 소스코드의 양 감소

- 간단할 설정 및 관리, 여러 기능의 추가가 쉬움

이제 Spring Boot 프로젝트를 만들어

GET, POST, PUT, DELETE 방식의 웹 서비스(Rest API)의 사용방법을 익혀보겠다.

준비과정

난 IntelliJ 가 커뮤니티 버전이라, Spring Initializr 로 프로젝트를 다운받아 사용해야 한다.

Spring Initializr : https://start.spring.io

Spring Initializr 에서 Gradle - Java- Spring Boot(2.6.2) - Dependencies [Spring Web] 을 선택한 후 zip 파일을 다운 받아, IntelliJ에서 열어주었다.

1. Get API

프로젝트 실행 - main 아래 [controller] 패키지 생성 - 패키지 안에 [GetAPIController.java] 생성

[GET 예제 코드 - 1]

1. @RestController

2. @RequestMapping("/uri") // 원하는 이름으로 지정해준다.

3. Get을 확인할 테스트 메소드(public String testGetMapping()) 만들기

4. @GetMapping(path="/uri2") // 원하는 이름으로 지정해준다.

5. 프로젝트 Run

6. Talend API tester (Google Chrome extension) 에서 GET 으로 확인해보기

성공적으로 상태코드 200과 함께 리턴된 메세지를 확인할 수 있었다.

package com.example.demo.controller;

import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.RequestMapping;
import org.springframework.web.bind.annotation.RestController;

@RestController // 1. RestController 추가
@RequestMapping("/demo") //2. RequestMapping 으로 시작 Path 지정
public class GetAPIController {

	@GetMapping(path = "/test") // 3. GetMapping 에 path 추가, http://localhost:8080/demo/test
	public String testGetMapping(){
    return "test get mapping";
	}
}

같은 코드지만 다른 방식으로는 @RequestMapping(path="", method = RequestMethod.GET)으로 써줄 수 도 있다.

package com.example.demo.controller;

import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.RequestMapping;
import org.springframework.web.bind.annotation.RequestMethod;
import org.springframework.web.bind.annotation.RestController;

@RestController // 1. RestController 추가
@RequestMapping("/demo") //2. RequestMapping 으로 시작 Path 지정
public class GetAPIController {

	@RequestMapping(path="/test", method= RequestMethod.GET)
	public String testGetMapping2(){
    return "test get mapping";
	}
}

[GET 예제 코드 2- @PathVariable]

일관적이지 않은 URI일 경우에 우리는 @PathVariable 을 사용한다.

예를 들어 사용자 아이디같은 경우라면

/demo/test/user1

/demo/test/user2 .. 처럼 사용자 아이디에 따라 계속 바뀌기에 우리는 고정된 URI를 사용할 수 없다.

이런 경우에 @PathVariable 코드를 써주면 된다.

package com.example.demo.controller;

import org.springframework.web.bind.annotation.*;

@RestController // 1. RestController 추가
@RequestMapping("/demo") //2. RequestMapping 으로 시작 Path 지정
public class GetAPIController {

    @GetMapping("/test/{userID}") //3. {변화하는 값}
    public String pathVariable(@PathVariable String userID){
        return userID;
    }
}

/test/{userID} 에 user100을 넣어주었고 Get이 정상적으로 동작하여 user100이 return 된 것을 Body에서 확인할 수 있다.

[GET 예제 코드 3- @RequestParam]

http://localhost:8080/demo/query?userId=100&name=ellie

이런식의 주소를 본 적이 있을 것이다.

?를 기준으로 key=value&key=value로 이어진 형태로, 이런 경우에는 @RequestParam을 활용하면 된다.

방법 1 - Map 사용

import org.springframework.web.bind.annotation.*;

import java.util.Map;

@RestController // 1. RestController 추가
@RequestMapping("/demo") //2. RequestMapping 으로 시작 Path 지정
public class GetAPIController {

//http://localhost:8080/demo/query?userId=100&name=ellie
//방법1. Map 사용    
@GetMapping(path = "test1")
    public String queryTest1(@RequestParam Map<String,String> queryTest){
    
    StringBuilder sb = new StringBuilder();
    queryTest.entrySet().forEach( entry -> {
        System.out.println(entry.getKey());
        System.out.println(entry.getValue());
        System.out.println("\n");
        
        sb.append(entry.getKey()+" = "+entry.getValue());
    });
}

방법2 - 각 변수에 @RequestParam 붙이기

package com.example.demo.controller;

import org.springframework.web.bind.annotation.*;

@RestController // 1. RestController 추가
@RequestMapping("/demo") //2. RequestMapping 으로 시작 Path 지정
public class GetAPIController {

    //방법 2 : 각 변수를 명시해주기 (사용해주는 Key 값을 알기위해서)
    @GetMapping("test2")
    public String queryTest2(
            @RequestParam String userID,
            @RequestParam String name
    ){
        return userID+" " +name;
    }
}

방법3 - 클래스 따로 만들기

package com.example.demo.controller;

import com.example.demo.User;
import org.springframework.web.bind.annotation.*;

@RestController // 1. RestController 추가
@RequestMapping("/demo") //2. RequestMapping 으로 시작 Path 지정
public class GetAPIController {

    //방법 3: 변수가 많아, 외부 클래스를 따로 만들어 불러오기
    @GetMapping("test3")
    public String queryTest3(User user){
        return user.toString();
    }
}

Talend API tester에 아래와 같이 Query Parameters 를 추가하고 Send 를 하면 성공적으로 값을 받아온 것을 확인할 수 있다.

References

https://bambooagile.eu/insights/pros-and-cons-of-using-spring-boot/

https://mangkyu.tistory.com/49

REST API

Ellie_yoon — Thu, 6 Jan 2022 22:12:34 +0900

REST란 무엇인가?

REST (Representational State Transfer: 자원의 상태 전달)

- 말 그대로 자원(Resource)을 표현(Representation)으로 구분하여 상태를 주고 받는 것(Transfer-Verb)으로, 웹의 장점을 최대한 활용하기 위해 쓰이는 아키텍쳐 스타일이다.

REST API(Application Programing Interface)

-REST 기반으로 API를 구현한 것.

RESTful

- REST의 조건을 잘 갖춘 웹 서비스를 일컫는 용어로 주로 REST API를 제공하는 웹서비스를 RESTful 하다고 표현합니다.

REST의 구성요소

(1) 자원(Resource) - URI(Uniform Resouce Identifier)

- 특정 자원의 식별자(Identifier)이다. e.g) '/study/rest_api'

- 자원은 서버에 존재하며, 클라이언트는 URI 로 자원을 지정하여 조작을 서버에 요청한다.

# URL (Uniform Resource Locator) 와의 차이점은?

-URL은 특정 자원(URI로 식별할 수 있는 자원)에 접근할 수 있는 위치(locator), 즉 파일 식별자를 일컫는다.

e.g.) https://www.ellie-yoon.tistory.com/study/rest-api.pdf

-따라서 URL 은 URI 의 하위 개념이다.

(2) 표현(Representation)

- 클라이언트가 자원을 지정하여 조작을 서버에 요청하면, 서버는 적절한 응답을 보낸다.

- 자원의 형태는 XML, JSON, TEXT 로 다양하다. (JSON이 더 자주 쓰인다)

(3) 행위(Verb) - HTTP Method(GET, POST, PUT, DELETE)

- 자원에 행해지는 행위는 HTTP Method에 의해 일어난다.

- HTTP Method 는 GET, POST, PUT, DELETE 등이 있으며 이를 통해 CRUD (Create, Read, Update, Delete) Operations 을 할 수 있다.

[Resource] URI 설계 원칙

계층관계에서 슬래시 구분자(/) 사용 e.g) https://ellie-yoon.tistory.com/web/spring
소문자 사용
언더바(_) 대신 하이픈(-) 사용 e.g) https://ellie-yoon.tistory.com/web/rest-api
URI 마지막에는 슬래시 포함하지 않음
프로그래밍의 메소드명(행위)는 포함하지 않음 e.g) https://ellie-yoon.tistory.com/web?action='sth'
파일 확장자는 URI에 포함하지 않음 e.g) https://ellie-yoon.tistory.com/web/index.jsp
명사형을 사용하되, 컨트롤러를 일컫을 때는 예외적으로 동사 허용 e.g) https://ellie-yoon.tistory.com/book/order
명사에 단수형보다는 복수형으로 사용 e.g) https://ellie-yoon.tistory.com/web/courses
세션 ID 는 포함하지 않음 e.g) https://ellie-yoon.tistory.com/web?session-id=ellie
CRUD 기능을 나타내는 이름은 URI에 사용하지 않음
일관성있게 서브 도메인을 사용한다. e.g.) (1) https://ellie-yoon.tistory.com/ (2) https://rest-api.ellie-yoon.tistory.com/

URI 정의와 설계원칙은 아래 링크에서 자세하게 확인이 가능하다.

https://datatracker.ietf.org/doc/html/rfc3986

[Verb] HTTP Method

	의미	CRUD	멱등성	안전성	Path Variable	Query Parameter	Data Body
GET	리소스 취득	R	O	O	O	O	X
POST	리소스 생성	C	X	X	O	권장X	O
PUT	리소스 갱신	C/U	O	X	O	권장X	O
DELETE	리소스 삭제	D	O	X	O	O	X
HEAD	헤더 데이터 취득	-	O
OPTIONS	지원하는 메소드 취득	-	O
TRACE	요청메세지 반환	-	O
CONNECT	프록시 동작의 터널 접속으로 변경	-	X

이 HTTP Method들은 다음과 같은 URI 형태로 사용되어 진다.

GET: 사용자 정보 요청(READ)

http://ellie.com/user/1
POST: 사용자 정보 생성(CREATE)

http://ellie.com/user
PUT: 사용자 정보 생성 및 업데이트(CREATE OR UPDATE)

http://ellie.com/user/1
DELETE: 사용자 정보 삭제

http://ellie.com/user/1

REST API 특징

(1) Server-Client (서버-클라이언트)

: 서버와 클라이언트의 독립적인 구조로 서로간의 의존성을 낮춤.

(2) Stateless (무상태성)

: 클라이언트의 상태정보를 따로 저장하지 않고 (세션 정보나 쿠키를 별도 저장 관리 X) 서버로 들어오는 요청만 단순 처리함.

(3) Cacheable (캐시 처리 가능)

: 클라이언트는 서버의 응답을 임시저장(Cache)하고, Cache를 통한 응답의 재사용을 하여 서버의 부하를 낮춤. Last-Modified 태그나 E-Tag 태그 를 사용하여 HTTP의 캐싱 기능 사용가능.

(4) Layered System (계층형 구조)

: REST 서버는 다중 계층으로 구성이 가능하여, 구조상으로 유연하며 확장가능함.

(5) Uniform Interface (인터페이스 일관성)

: URI로 지정 자원의 조작을 통일하고, 한정적인 인터페이스로 수행하여 일관성을 유지 및 아키텍처를 단순화가능.

(6) Code on Demand (Optional)

: 옵셔널한 특징, 서버로 부터 자바 애플릿, 자바스크립트, 플래시 등 특정 기능을 Client 가 전달받아 실행하는 것

References

https://fastcampus.co.kr

https://meetup.toast.com/posts/92

https://gmlwjd9405.github.io/2018/09/21/rest-and-restful.html

HTTP 상태코드

Ellie_yoon — Wed, 5 Jan 2022 01:49:18 +0900

HTTP 상태코드 (응답코드) : 클라이언트의 요청 (Request)에 대한 응답(Response)에 대한 상태를 코드로 알려주는 것

상태코드는 1부터 5까지로 구성되어 있다.

Response Code Syntax	Response Code	설명
1XX	Informational	서버가 요청을 받아 처리중인 상태 (어떤 형태의 문제도 X)
2XX	Success	요청한 작업이 성공적으로 처리됨
3XX	Redirection	요청을 처리하기 위해 추가 동작이 필요함 (Redirection: 요청된 위치에서 리소스를 더 이상 사용할 수 없음을 알림)
4XX	Client Error	클라이언트의 요청에 오류가 있는 상태
5XX	Server Error	서버가 오류가 발생했거나 요청을 수행할 수 없는 상태

1XX ( Informational : 조건부 응답)

: 클라이언트의 요청을 처리중인 상태

1) 100: Continue

- 서버에 클라이언트의 요청의 시작 부분이 받아들여졌으며 나머지를 기다리고 있는 상태.

2) 101: Switching Protocols

- 클라이언트가 서버에 프로토콜 전환을 요청했을 때, 서버가 이를 승인한 경우(변경 중임을 알려주는 상태코드).

3) 102: Processing

- 서버가 요청을 수신하고 처리중인 상태라 아직 응답을 할 수 없는 상태.

4) 103: Early Hints

- Link 헤더와 함께 사용되어 서버가 응답을 준비하는 동안 클라이언트가 사전 로딩(Pre-loading)을 할 수 있도록 하는 응답코드.

2XX (Success: 성공)

: 클라이언트의 요청을 수신하여 성공적으로 처리한 상태

1) 200: OK

- 요청 정상 처리됨.

2) 201: Created

- 요청이 정상 처리되어 리소스가 만들어짐.

3) 202: Accepted

- 요청은 승인됐지만, 처리되지는 않은 상태.

4) 204: No Content

- 요청은 정상 처리되었지만 응답에 본문(Body)가 없어 돌려줄 리소스가 없음.

- 처리 후 클라이언트에게 정보를 보낼 필요가 없는 경우에 사용됨

5) 206: Partial Content

- 리소스의 일부분만 제공되는 경우.

- 범위(range)가 지정된 요청일 경우에 사용된다. 예를 들면 클라이언트에서 다운로드 범위를 지정한 경우에 그 부분만 제공하기 위해 사용됨.

3XX (Redirection: 리디렉션 완료)

: 요청을 처리하는데 추가동작이 필요

1) 300: Multiple Choices

- 클라이언트의 요청에 대해 서버에서 여러 개의 응답이 있을 때, 사용자 에이전트 또는 사용자는 하나의 응답을 선택해야 함.

- 응답을 선택하는 방법은 표준화되지 않아 잘사용되지 않음.

2) 301: Moved Permanently

- 요청한 리소스의 URI가 영구적으로 변경됨 (새 URI를 사용해야함).

- 리다이렉트시, HTTP 메소드를 GET로 바꿔서 전송함.

3) 302: Found

- 요청한 리소스의 URI가 일시적으로 변경되었기에, 클라이언트는 향후 요청을 반드시 동일한 URI로 해야함.

- 리다이렉트시, HTTP 메소드를 GET로 바꿔서 전송함.

4) 303: See Other

- 요청한 리소스가 다른 URI에 있어서 별도의 GET 요청을 해서 얻어야 하는 경우, 서버가 클라이언트로 직접 보내는 응답임

5) 304: Not Modified

- 캐시 목적으로 사용됨

- 마지막 요청 이후에 리소스가 수정되지 않음을 알려주며, 클라이언트는 응답의 캐시된 버전 (로컬 캐시 리소스)를 사용할 수 있음.

- 리디렉션과는 관계없는 처리를 함

6) 307: Temporary Redirect

- 302 (요청한 리소스의 URI가 일시적으로 변경)와 같지만, 리다이렉트시 HTTP 메소드가 유지됨.

e.g.) POST로 요청했다면, 리다이렉트 시에도 POST 로 요청해야 한다.

7) 308: Permanent Redirect

- 301 (요청한 리소스의 URI가 영구적으로 변경됨)와 같지만, 리다이렉트시 HTTP 메소드가 유지됨.

e.g.) POST로 요청했다면, 리다이렉트 시에도 POST 로 요청해야 한다.

# Permanent Status - 301과 308은 상태는 유사하지만, 301은 리다이렉트시, HTTP 메소드를 GET 으로 바꿔서 전송하고, 308은 첫 HTTP 메소드를 리다이렉트시도 그대로(유지) 사용한다.

# Temporary Status - 302와 307은 상태는 유사하지만 302은 리다이렉트시, HTTP 메소드를 GET 으로 바꿔서 전송하고, 307은 첫 HTTP 메소드를 리다이렉트시도 그대로(유지) 사용한다.

4XX (Client Error: 클라이언트 에러)

: 클라이언트 측의 문제로 요청을 처리할 수 없는 상태

1) 400: Bad Request

- 클라이언트 쪽의 에러로 서버가 요청을 처리할 수 없는 상태 (잘못된 형식의 요청 구문)

2) 401: Unauthorised

Unautorised 로 표기되어 있지만 Unauthentication 이 더 이해하기 가까운 표현!

- 요청에 사용자 인증이 필요한 경우 (로그인 페이지 등).

- 응답에는 요청된 리소스에 적용할 수 있는 문제가 포함된 WWW-Authenticate 필드가 포함되어야 함 ( 어느 인증 방식을 사용할 것인지).

- 단순한 클라이언트 권한이 없는 경우는 403 Forbidden 사용해야 함.

3) 403: Forbidden

- 클라이언트가 접근할 권한이 없어, 서버가 요청을 거부하는 경우.

- 서버는 요청을 이해했고 클라이언트를 알고 있음, 단순히 접근권한 불충분으로 승인을 거부한 경우.

4) 404: Not Found

- 요청한 리소스를 찾을 수 없음.

5) 405: Method Not Allowed

- 클라이언트가 허용되지 않는 HTTP 메서드를 요청했을 경우.

- e.g) POST 요청받는 서버에 GET 으로 보내는 경우.

6) 407: Proxy Authentication Required

- 401과 비슷하지만, 클라이언트가 프록시에 의해 완료된 인증이 필요한 경우.

7) 408: Request Timeout

- 요청 시간이 초과된 경우.

8) 409: Conflict

- 요청이 서버의 상태와 충돌한 경우.

5XX (Server Error: 서버 에러)

: 서버가 요청을 수행하는데 문제가 발생한 상태

1) 500: Internal Server Error

- 서버가 요청 처리 중에 발생한 오류.

2) 502: Bad Gateway

- 서버가 게이트웨이에서 잘못된 응답을 받은 경우 (다른 서버로 부터 유효하지 않은 응답을 수신한 경우).

3) 503: Service Unavailable

- 서버가 요청을 처리할 수 없는 상태.

- 서버 과부화나 유지보수중의 이유로 요청 처리 불가함.

4) 504: Gateway Timeout

- 게이트웨이 역할을 하는 서버가 연결된 다른 서버로 부터 응답시간이 초과된 상태.

- 서버 간의 네트워크 오류이거나 실제 서버의 문제일 가능성이 큼.

5) 505: HTTP Version Not Supported

- 요청에 사용된 HTTP 버전이 해당 서버에서 지원이 안되는 경우.

Swift 3-2장 반복문 (for-in, while, repeat-while)

Ellie_yoon — Tue, 28 Dec 2021 15:32:28 +0900

오늘은 Swift의 반복문에 대해서 다뤄보겠다! :)

반복문은 말그대로 반복적으로 해당되는 코드블럭을 실행하게 만드는 구문이다.

Swift 의 반복문 키워드는 대표적으로 for-in, while, repeat-while 이 있다.

하나씩 살펴보도록 하자

1. for - in

for 상수 초기식 ; 조건식 ; 변화식 {

코드 블럭

}

에 익숙한 사람이라면 자연스럽게

이런식의 코드를 쓰겠지만, "이런 C 스타일의 구문은 siwft3에서 지워졌다." 라는 에러메세지로 알 수 있듯이,

더 이상 저런 형식의 for문은 사용할 수가 없다.

그 대신에 Swift 에서는 for-in 구문을 써주면 된다!

for - in 은 in 때문에 생소할 수 있을 수 있고, 아마 파이썬을 한 사람이면 익숙할 것이다.

어려울 것 없이 순회대상 또는 범위가 있는 코드에 써주면 된다.

구조는 다음과 같다.

Swift 에서는

for <값> in <순회범위> {

코드블럭

}

사용예제를 살펴보자

numbers 라는 배열이 있고 i 는 그 배열을 순회하며 출력한다.

따라서 결과값은 1,2,3,4,5 차례대로 출력된다.

특정한 조건을 달고 싶다면 조건문 if를 넣어주어도 된다.

i는 위 코드 예제처럼 배열을 순회한다. 다만 달라진 점은 if문의 등장으로 i가 2로 나눠 나머지가 0일 때, 즉 짝수일때만 출력하라는 조건식을 써주었다.

결과값은 당연히 배열 내의 짝수인 2,4 가 출력된다.

마지막 for-in 예제

이번에 in <범위대상> 을 직접 써줬다. ...의 사용으로 범위는 i >= 1 && i<=3 (1 이상 3이하) 인 [1,2,3]이 된다.

result 의 초기값은 1로 설정하고 i의 값을 루프를 돌때마다 result에 곱해준다.

결과값은 1,2,6 이 될 것이다.

2. while

while 은

while 조건식 {

코드블럭

}

의 구조로, 조건식에 맞다면 해당 코드블럭을 계속 실행한다.

예제를 들어보자

count = 0 으로 초기화 되어있고, 그 값이 50보다 작다면 계속 1씩 증가할 것이다.

count 는 0 부터 49까지 점차 값이 증가할 것이고, 49일때 까지만 조건식을 충당해 코드 블럭내로 들어가고

그 안에서 1이 더해진 다음 50이 되어 while 루프 밖을 빠져나온다.

따라서 루프 밖에서 50이라는 결과값이 출력되는 것!

다음으로 이 코드 구문을 repeat-while 을 이용하여 써보겠다.

3. repeat-while

repeat - while 문은 do - while로 이해하면 된다.

repeat {

실행 구문

} while(조건식)

의 구조를 가지고 있다.

컴파일러는 repeat 내를 먼저 실행하고 while의 조건식이 맞는지 비교한다.

결과값은 50이 출력될 것이다. (count2 가 49일때 1이 더해져 50이 되기 때문에 조건식에 맞지 않아 해당 루프를 빠져나오기 때문!)

마지막 repeat-while 예제를 살펴보겠다.

1씩 증가하는 i를 total 에 더해주는 구문이다. 다만 여기서 조건은 i 가 10 보다 작을 때 까지기 때문에

i 는 초기값인 0 부터 9까지 증가하며 그 값을 total 에 더해준다.

결과값은 아래와 같다.

오늘은 이렇게 Swift 의 반복문에 대해 다뤄보았다. 다음 파트에서는 옵셔널과 옵셔널 바인딩을 해야겠다!

Swift 3-1장 - 조건문 (if, switch, guard)

Ellie_yoon — Mon, 20 Dec 2021 13:57:17 +0900

앞서 함수를 배웠으니 이쯤되면 등장해야하는 조건문에 대해서 알아보자

1. 조건문 (if, switch, guard)

- 주어진 조건에 따라 명령을 수행하는 문장, 즉 조건의 참과 거짓을 판별하여 참일 때 수행된다.

- Swift 에서의 조건문 : if, switch, guard

하나씩 사용법을 알아보도록 하자

(1) if

swift 의 if문은 다음과 같은 형식으로 써주면 된다.

예제 코드로는 홀수와 짝수 판별식을 만들어보자

if 문의 조건이 성립한다면 즉, 2로 나눈 나머지가 0 이라면 "짝수입니다." 를 출력할 것이고, 그렇지 않다면 (else) 다음 else 구문안의 문장을 출력할 것이다.

따라서 num이 3일때: if 조건문 성립 X -> else 문으로 이동 후 실행

num이 6일때: if 조건문 성립 O, 실행

만약에 조건이 3개 이상이라면? else if 를 사용해주면 된다

myMark

조건 1: 점수가 90 이상이면 A

조건 2: 80-90 사이면 B

조건 3: 둘 다 아니면 C

위 같은 경우는 switch 문으로 하는 게 낫겠지만 좋은 예시가 생각나지 않으니 이걸로 해보자

if ~ else if ~ else

(2) switch

- switch 는 입력변수에 매칭되는 case 가 실행된다.

- 반복적으로 if, else - if 를 써야되는 상황이라면 switch 문으로 써주는게 가독성이 더 좋고 적합할 때가 있다.

위에서 if 문에서 사용한 myMark를 좀 더 세부화시켜서 switch 구문으로 바꿔보자

myMark

조건 1: 점수가 90-100 사이면 A

조건 2: 80-90 사이면 B

조건 3: 70-80 사이면 C

조건 4: 60-70 사이면 D

조건 5: 60 미만이면 F

mark 가 입력변수이기 때문에 따로 조건에 맞는 case 구문을 실행한다. 사이에 있는 값은 ... 으로 표현한다

하지만 위의 if 조건절처럼 mark > 90 이런식으로 쓸 수 있을까?

바로 다음과 같은 에러가 발생한다. " Expression pattern of type 'Bool' cannot match values f type 'Int' "

위 switch 구문에서 입력변수의 데이터타입은 Int이다.

따라서 매칭되는 case 를 찾기 위해서는 case 조건부분이 같은 Int 이어야 한다는 것이다.

하지만 mark >= 90 이 부분은 참과 거짓으로 판단되는 Bool 타입이기에 다음과 같은 에러가 발생하는 것이다.

그래서 굳이 비교등호가 필요하다면 다음과 같이 써주면되겠다.

오류 해결 - 1번 방법

1번 방법이다. boolean의 case 를 써야된다면, 입력 변수 값을 같은 boolean으로 변경해주면 된다.

switch를 실행시켜야 하기에 당연히 true 를 써주고, 아래 case 수식을 아까 쓰지 못한 등호를 사용하여 완성한다.

하지만 보기에도 좋은 코드는 아닌 듯하니 참고만 하자!

오류 해결 - 2번 방법

입력 변수 타입을 바꾸지 않겠다면 case _ where 을 추천한다.

혹시 sql 을 공부했었던 사람이면 눈치챘겠지만 where 은 뒤에 조건식을 데리고 다닌다. 그래서 데이터베이스에서 특정 데이터 값을 찾을 때 where FirstName = 'Ellie' 이런식으로 필터링해서 조건에 맞는 데이터 값을 찾는 것이다.

이처럼 mark의 조건식(where)이 충족한다면 해당 case 는 실행될 것이다.

(3) guard

- guard 는 우리가 아는 뜻 그대로 무언가를 막는 것이다. 따라서

guard 문은 함수 내에서 입력값의 오류로 프로그램이 종료되는 것을 막기위해 사용해준다.

Q: 그렇다면 잘못된 값일 때의 처리를 어떻게 해줄까?

A: else 구문과 함께 return , throw, break 등 으로 함수의 실행을 막거나 함수를 나가게 하면된다.

그래서 guard - else 는 항상 한 세트로 다니니 기억하도록 하자

guard 예시코드

input 앞에 guard 가 붙어있으므로 해당 함수는 input 이 1 일때만 실행된다.

결과에서 알 수 있듯이 1을 입력하면 함수가 실행이 됐지만, 2를 입력하니 return 되어 결과가 없는 것을 확인할 수 있다.

Q: 보면서 if 같다고 생각하는 사람이 많을 것이다. 둘의 차이는?

A: if와 다른점은 코드블럭의 수행을 막기위해 if는 부정의 조건식을 쓰지만, guard 는 수행에 필요한 조건을 그대로 나타내어 훨씬 가독성이 좋습니다.

Q: 여러식의 조건문을 쓰고 싶을 때는?

A: Guard 문은 쉼표(,)로 구분하여 여러 조건을 쓸 수 있다.

여러식의 조건문을 쓴 간단한 예시 코드는 다음과 같다.

로그인을 하려면 아이디와 비밀번호 두 개의 필드가 입력되어야만 다음으로 진행이 가능하다.

필드값이 비어있지 않은 경우, 즉 != nil일 경우에 guard 문을 붙이고, 비어있을 경우 (else) 에는 return 을 메세지 출력과 함께 return 을 시켜주자.

guard로 사용자 아이디와 비밀번호 필드값 입력 확인하기

따라서 테스트한 부분을 보면 아이디와 비밀번호가 nil 일 때는 결과값으로 else 문의 코드블럭에 있던 "아이디와 비밀번호가 입력되지 않았습니다. " 가 출력이 되고,

아이디와 비밀번호에 문자열을 입력해준 후 실행하면 guard 문을 통과하여 성공적으로 "아이디와 비밀번호가 입력되었습니다. " 가 출력되는 것이다.

오늘의 조건문 끝! 사실 반복문까지 다루고 싶었지만 포스트가 너무 길어질까봐 다음장에서 하도록 하겠다!