24. 12. 17 기록
요즘따라 시간이 빠르게 지나간다. 공부도 얼마 못한 것 같은데 '왜.. 벌써.. 저녁?'
아무래도 트러블 슈팅에 TIL에 작성해야할게 산더미이다 보니 더 그렇게 느껴지는 것 같다.
API 하나 구현하다 궁금한게 생기면 찾아보고, 트러블 슈팅 쓰면서 자료 찾아보고...
정신없이 궁금증을 해결하다보면 1시간, 2시간은 훌쩍 지나간다.
이것저것 찾아보느라 오늘도 과제 구현은 느림보 달팽이지만, 그래도 새로 알게된 것들이 많아서 정말 기쁘다!
새로 알게된 내용을 간략히 정리해본다.
@RequiredArgsConstructor이 뭘까?
@RequiredArgsConstructor는 롬복(Lombok) 라이브러리에서 제공하는 애노테이션다.
클래스에 있는 final 필드와 @NonNull 애노테이션이 붙은 필드들을 매개변수로 받는 생성자를 자동으로 생성해준다.
[예시]
import lombok.RequiredArgsConstructor;
@RequiredArgsConstructor
public class Example {
private final String name;
private final int age;
private String address;
//아래와 같은 생성자를 만들어준다.
public Example(String name, int age) {
this.name = name;
this.age = age;
}
}
위 코드에서 address는 final이 아니기 때문에 생성자 매개변수에서 제외된다.
데이터가 없으면? 200 OK vs 404 Not Found
오늘 회원 정보 조회 API를 구현하면서 가장 많이 고민한 부분이다.
"데이터가 없으면 어떤 상태코드를 사용해야할까?"
해당 문제에 대해서는 사람들마다 약간씩 생각이 다른 것 같다.
일단 나는 '200 OK'를 사용해야한다고 생각한다.
조회하려는 데이터가 없을 뿐이지 요청 방식에는 딱히 문제가 없다고 판단했기 때문이다.
처음 HTTP Status에 대해 배울 때 400번대는 클라이언트측 오류라고 배웠는데, 조회하려는 데이터가 없는건 클라이언트 문제가 아니라고 생각한다.
따라서 요청은 정상적으로 처리되었으나 응답할 정보가 따로 없다는 것을 알려주는게 맞지 않을까?
위 생각의 연장선으로, 오늘 API를 구현하면서 응답할 정보가 없다는 의미를 담아 204 No Content를 사용했다가 Body가 깔-끔하게 사라져서 당황스러웠던 경험도 했다.
204 No Content의 의미를 오해해서 일어난 일인데, 해당 사건과 관련된 글은 트러블 슈팅에 따로 정리해두었다.
여튼 200 OK를 사용하는게 Body에 구체적인 정보도 담아서 알려줄 수 있고,
클라이언트에게 '너의 요청 방식은 문제가 없어! 그저 건내줄 정보가 없을 뿐.' 이라는 것도 명확하게 전달할 수 있어서 더 좋은 선택일 것 같다.
물론 팀원과 논의하는게 제일 중요!
아래는 오늘 HTTP Status에 대해서 고민하다가 찾은 글인데, 오늘 한 고민과 닮았고, 개인적으로 재미있게 읽어서 공유해본다.
데이터가 없을 때 200인가 404인가?
오류가 아닌데 왜 4xx로 반환하는 거예요?
techblog.yogiyo.co.kr
위에 정리한 내용 외에도 개인적으로 Exception을 구현하거나, JSON 직렬화 과정에 대해 알아보는 등 많은 것을 새로 배웠다. 다만 과제 구현 중 마주한 문제 해결을 위해 찾아본 내용들이라 트러블 슈팅에 따로 정리해두었다.
요즘 밥 먹는 시간도 너무 아까워서 저녁은 항상 우유 한 팩으로 간단하게 때우게 된다.
그래도 하루종일 가만히 앉아만 있어서 그런지 배는 별로 안 고픈게 다행이랄까 😶❔
하지만 건강은 중요하니까 최대한 건강하게 끼니를 해결할 수 있도록 신경써야겠다 :)
'TIL > 데일리 기록' 카테고리의 다른 글
| [TIL] TIL은 TIL 답게 (1) | 2024.12.16 |
|---|