티스토리 뷰

FieldError

 

Controller 에서 파라미터 에러가 날 경우, BindingResult 로 바인딩 결과를 받아올 수 있다.

예를 들어서, 컨트롤러 단에서 아래와 같이 사용할 수 있다.

 

public class ItemApiController {
    private final ItemService itemService;

    @PostMapping("item/enroll")
    public ResponseEntity enroll(@Valid @RequestBody ItemDto itemDto, BindingResult result){
        if (result.hasErrors()){
            throw new InvalidParameterException(result);
        }
// .. 생략

 

@Valid 에서 실패한 것은 예외가 던져지고, 그 예외 안에는 BindingResult 가 담겨있게 되는 것이다.

여기서 BindingResult 는 검증 오류가 발생할 경우에 오류 내용을 보관하는 객체이다. (스프링에서 제공)

 

따로 에러 필드에 대한 확인이 가능하다. 

 

문제가 되는 코드, 필드명, 필드 메시지가 있다면 기본 메시지와 실패 이유를 알 수 있도록 메서드가 내장되어 있다.

 

fieldError.getCode()

fieldError.getField()

fieldError.getDefaultMessage()

fieldError.getRejectedValue()

 

와 같이 사용 가능하다.

 

https://namocom.tistory.com/881

 

[Spring] FieldError의 계층구조

스프링 Controller에서 파라미터 에러가 나면 BindingResult 로 바인딩 결과를 받아 올 수 있다. @RestController @RequestMapping(value = "/some") public class SomeController { @PostMapping(value = "/thing..

namocom.tistory.com

 

웹소켓

 

등장배경

HTTP 를 통해서 데이터를 가져오기 위해서는 URL을 통한 요청만이 유일한 방법이었다. 즉, 매번 새로운 페이지 요청을 해야 했다. 그러나 Ajax 통신 방식의 등장을 통해 클라이언트에서 XMLHttpRequest 객체를 이용해서 서버에 요청을 보내면 서버가 응답할 수 있게 되었다. 따라서 부분적으로 정보를 갱신할 수 있게 됐다. 이를 통해서 서버로부터 새로운 HTML 을 받아야 하는 것이 아니라 동일한 페이지의 일부를 수정할 수 있게 된 것이다. 사용자 입장에서는 페이지 내부의 변화만 일어나기 때문에, 자원과 시간을 아낄 수 있다. 그러나 이도 결국에는 요청을 보내야 응답이 오는 형태이다. 변경되는 데이터를 가져오기 위해서는 일정 주기로 새로운 요청을 보내야 한다는 것이다. ex) 주가 확인

 

장점

이러한 이유로 등장한 것이 웹소켓이다. 이는 서버와 클라이언트 간에 양방향 소통이 가능하게 한다. 하나의 HTTP 접속을 통해서 양방향 메시지를 주고받을 수 있는 것이다. 이전에는 클라이언트의 요청이 없으면 브라우저가 서버로부터 응답을 받을 수 없었다. 그러나, 웹소켓을 통해서는 서버와 브라우저 간의 소통이 가능해진다. 브라우저는 클라이언트의 요청 없이 서버가 보내는 데이터를 받아들이고 최신 데이터가 적용된 웹을 확인할 수 있게 된다. ex) 실시간 채팅 / 실시간 주식차트

 

일정 시간이 지나면 HTTP 연결이 자동으로 끊어지는 방식으로 동작한다.

 

문제점

복잡하다.

Stateful Protocol 이기 때문에 서버와 클라이언트가 항상 연결되어 있어야 한다.

또한 그 자체로 비용이 들 수 있고 (트래픽이 많으면 더 부담이 된다.) 오래된 브라우저에서는 지원하지 않는다.

 

Stateful ? Stateless?

Stateless 즉 무상태 프로토콜인 상태에서는 서버가 클라이언트의 상태를 보전하지 않는다.

예를 들어 동영상을 이전 재생시점부터 재생한다고 가정했을 때, Stateful 에서는 사용자가 종료한 시점이 서버에 저장되어 있고 이를 다시 재생시켰을 때 서버에서 동영상의 정보와 종료 시점 등을 받아와서 그 시점부터 재생한다. 따라서 서버를 증설할 시에 다른 서버를 이용하게 된다면 이전에 종료한 시점을 알 수가 없다.

Stateless 무상태 프로토콜을 사용한다면 동영상 정보 및 동영상 종료 시점 등의 정보를 서버에 보내서 종료한 시점부터 재생한다. 따라서 서버 증설 시에도 문제가 되지 않는다. 왜냐하면 요청 시에 정보를 보내는 것이지 서버에 정보를 저장해두는 것이 아니기 때문이다. 

상태를 유지하는 것의 예시에는 로그인 할 시에 사용하는 쿠키나 세션을 생각하면 된다. 

 

 

https://choseongho93.tistory.com/266

 

[웹소켓] WebSocket의 개념 및 사용이유, 작동원리, 문제점

오늘은 웹소켓에 대해 알아보겠습니다. ● 웹소켓(WebSocket)의 배경 : 인터넷이 나오고 HTTP를 통해서 서버로부터 데이터를 가져오기 위해서는 오로지 URL을 통한 요청이 유일한 방법이었습니다. 때

choseongho93.tistory.com

https://devmango.tistory.com/m/68

 

Stateful, Stateless 차이, 비연결성(connectionless)

무상태 프로토콜 - 스테이스리스(Stateless) - 서버가 클라이언트의 상태를 보전하지 않는다. - 장점 : 서버 확장성 높음(스케일 아웃) - 단점 : 클라이언트가 추가 데이터를 전송해야 한다. Stateful, S

devmango.tistory.com

 

MSA (Micro Service Architecture)

 

하나의 큰 애플리케이션을 여러 개의 작은 애플리케이션으로 쪼개어 변경과 조합이 가능하도록 만든 형태.

독립적으로 배포 가능한 각각의 기능을 수행하는 서비스로 구성된 프레임워크. 독립적으로 배포가 가능하다. 

 

이와 반대되는 개념은 모놀리식 아키텍처이다. 모든 애플리케이션의 구성 요소가 하나의 프로젝트에 통합되어 있는 형태이다. 

모놀리식 아키텍쳐의 한계로 인해서 MSA 는 탄생했다. 이는 큰 규모의 프로젝트에서 한계를 보인다.

왜냐하면, 부분 장애가 전체 서비스의 장애로 확대될 수 있으며, 부분적으로 나누어 일을 처리하는 방식이 어렵다. 또한 서비스의 변경이 어렵고 장애의 영향 파악에도 힘들다. 

 

MSA 는 API 를 통해서만 상호작용할 수 있으며 end-point 만 노출하고 세부사항은 모두 추상화한다. 

이는 서비스별로 독립적인 배포가 가능하며, 개별적으로 scale-out 이 가능해서 CPU적으로 이득이 될 수 있다.

 

그러나 통합 테스트가 어렵고 분산되어 있기 때문에 복잡하다는 단점이 있다.

 

https://wooaoe.tistory.com/57

 

[MSA] MSA란 무엇인가? 개념 이해하기

MSA가 무엇인지 자세하게 알고싶어 개인적으로 정리하는 포스팅입니다. MSA? MicroService Architecture의 줄임말 👉🏻 마이크로서비스 아키텍처에 대한 정확한 정의는 없다. 하지만 마이크로서비스란

wooaoe.tistory.com

https://steady-coding.tistory.com/595

 

[데이터 분산 처리] MSA 아키텍처란?

cs-study에서 스터디를 진행하고 있습니다. 모놀리식 아키텍처 (Monolithic Architecture) 모놀리식 아키텍처는 마이크로서비스(MSA) 아키텍처에 반대되는 개념으로, 애플리케이션의 모든 구성 요소가 한

steady-coding.tistory.com

 

ResponseEntity

 

우선, @ResponseBody 를 먼저 보자.

 

ResponseBody 는 HTTP 규격에 맞는 응답을 만들기 위한 어노테이션이다.

이는 HTTP 요청을 객체로 변환하거나 객체를 응답으로 변환하는 HttpMessageConverter 를 사용한다.

이 Converter 는 response body 에 직렬화를 하는 방식으로 작동한다. 

 

그러나 이를 통해서는 Header 를 유연하게 설정할 수 없다. 또한 status 를 메서드 밖에서 어노테이션으로 설정해줘야 한다는 단점이 있다.

 

이를 극복하기 위해서 ResponseEntity 를 사용한다.

 

이는 어노테이션이 아닌 객체로 사용되며, 응답으로 변환될 정보들을 모두 담은 요소들을 객체로 만들어 반환해준다.

 HttpMessageConverter 가 본문을 처리해주고, 나머지 구성 요소인 Status 를 넘겨준다. 

 

ResponseEntity 내부에는 status 필드만 구성되어 있다. 나머지 필드들은 모두 HttpEntity 내부에 있다.

public class ResponseEntity extends HttpEntity {

  private final Object status;
}

 

HttpEntity 내부에는 header 필드가 있어 이를 통해서 직접 헤더를 설정해줄 수 있다. 또한, body 가 될 필드값을 가질 수 있는데 이는 Generic 타입으로 인해서 바깥에서 Wrapping 될 타입을 지정할 수 있다. 이는 자동으로 Body 에 들어갈 수 있도록 변환된다. 

public class HttpEntity<T> {
    public static final HttpEntity<?> EMPTY = new HttpEntity<>();
  
  
    private final HttpHeaders headers;
  
    @Nullable
    private final T body;
}

 

이는 Constructor 보다는 Builder 를 사용하는 것이 권장된다. 왜냐하면 숫자로 된 상태 코드를 넣을 시에 잘못된 코드를 넣을 수 있다는 이유 때문이다. 

 

return ResponseEntity.ok()
        .headers(headers)
        .body(moveResponseDto);

 

 

https://tecoble.techcourse.co.kr/post/2021-05-10-response-entity/

 

ResponseEntity - Spring Boot에서 Response를 만들자

웹 서비스에서는 많은 정보를 송수신하게 됩니다. 각각의 다른 웹 서비스들이 대화하려면, 서로 정해진 약속에 맞게 데이터를 가공해서 보내야합니다. 보내는 요청 및 데이터의 형식을 우리는 H

tecoble.techcourse.co.kr

 

댓글
공지사항
최근에 올라온 글
최근에 달린 댓글
Total
Today
Yesterday
링크
TAG
more
«   2025/06   »
1 2 3 4 5 6 7
8 9 10 11 12 13 14
15 16 17 18 19 20 21
22 23 24 25 26 27 28
29 30
글 보관함