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

 

'Web > Spring' 카테고리의 다른 글

Spring - AOP  (0) 2022.01.07
Spring - IoC/DI 란?  (0) 2022.01.07
Spring Boot 시작하기 1장 (Get API-@GetMapping)  (0) 2022.01.07

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 모두 제어

 

'Web > Spring' 카테고리의 다른 글

Spring Boot JSP & Thymeleaf  (0) 2022.06.08
Spring - IoC/DI 란?  (0) 2022.01.07
Spring Boot 시작하기 1장 (Get API-@GetMapping)  (0) 2022.01.07

저작자: PHẠM HUY HO&amp;amp;Agrave;NG 이미지 출처 :&amp;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

'Web > Spring' 카테고리의 다른 글

Spring Boot JSP & Thymeleaf  (0) 2022.06.08
Spring - AOP  (0) 2022.01.07
Spring Boot 시작하기 1장 (Get API-@GetMapping)  (0) 2022.01.07

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

'Web > Spring' 카테고리의 다른 글

Spring Boot JSP & Thymeleaf  (0) 2022.06.08
Spring - AOP  (0) 2022.01.07
Spring - IoC/DI 란?  (0) 2022.01.07

 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

 

 

'Web > Web 개론' 카테고리의 다른 글

HTTP 상태코드  (0) 2022.01.05
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 버전이 해당 서버에서 지원이 안되는 경우.

'Web > Web 개론' 카테고리의 다른 글

REST API  (0) 2022.01.06

+ Recent posts