영암사는 승경이네

1. 과제

 객체지향적인 REST API를 스프링 부트로 구현하라.

2. 배운점

2.1. HTTP Status 를 개념있게 사용하자

 서버 오류가 발생했을 때는 500, 리소스가 없을때는 404, 성공했을 때는 200, 요청 값이 비정상적일때는 400. 개발을 하면서 내가 접했던, 그리고 아는 HTTP Status는 딱 이정도였다. 이번 과제를 진행하며 처음으로 201, 204 등의 코드를 접해보았으나 의미와 개념을 파악하지 않고 '메서드에 따라서 상태코드가 달라질 수 있구나' 라고만 생각하고 넘겼다.

알고보니 201은 요청성공 및 리소스 생성일때, 즉 Create한 요청을 보냈을 때의 상태코드이고, 204는 요청 성공했으나 응답값이 없을 때, Delete한 요청을 보냈을 때 사용 가능한 상태코드이다. 404도 클라이언트 자원(html, css, img 등)이 없을 때의 상태코드로 알고있었으나 클라이언트 자원 뿐 아니라 서버 리소스가 없을 때도 404 상태코드로 표현이 가능했다.

이를테면 id에 매핑된 정보를 수정요청할 때 서버에서 유효한 id 값인지 확인하게되는데 이 값이 없을 경우 상태코드를 404로 리턴해도 된다.

 100번 대는 정보응답, 200번 대는 성공, 300번 대는 리다이렉트 400번 대는 클라이언트 에러, 500번 대는 서버 에러로 백의자리 숫자에 따라 상태코드가 구분된다는 것도 처음 알게 되었다.

아래는 HTTP 상태코드에 대한 공식문서이다.

https://developer.mozilla.org/ko/docs/Web/HTTP/Status

2.2. 스프링 부트야 고맙다.

 1주차에서는 스프링 없이 Java로만 코드를 짜다보니 코드가 길어지고 시간도 많이들었다. 이번 주차에 스프링 프레임워크를 사용하니 훨씬 쉽고 깔끔한 코드를 구현할 수 있었다. 나쁘게만 보였던 스프링 부트가 조금은 착해보인다.

2.3. 공식문서 보는 습관을 들이자.

 람다식을 사용하니 멘토님께서 공식문서 주소를 주시며 한번 봐보라고 하셨다. 하지만 필자는 공식문서의 영어가 보이는 순간 자신감을 잃는다. 한글로 번역을 때리면 코드들도 번역이 되기에 블로그를 기웃기웃 거렸다.

 하지만 생각과 달리 공식문서에서 제공되는 예제 코드들은 정말 간단하고 이해하기 쉽게 되어있었다. 설명들은 번역기로 돌려가며 이해했고, 코드들은 쭉 코딩해보니 맥락이 이해되면서 예제코드도 이해되기 시작했다. 그리고 무엇보다 간지가 좀 나는것 같다. 공식문서를 읽는 개발자... 아무쪼록 공식문서를 보는 습관을 들여보겠다!

3. 느낀점

이번 과제는 1주차보다 빨리 끝났다. 이유는 스프링 문법을 사용했기 때문이다. 생각없이 사용했던 어노테이션과 스프링 문법들에 대해 생각의 여지를 갖게 해준 시간이었던 것 같다.

 HTTP Status 코드를 새롭게 이해하게 됐고, 공식문서를 보는 게 얼마나 중요한 것인지도 알게되었다. 뭔가 다음주차부터는 큰 고통받을 것 같아 두려운 마음이 있지만 멘토님이 있으니 걱정안한다. -ㅅ-