처음으로 백엔드와 협업!
그동안 리액트 공부를 하면서 나혼자 강의듣고 나혼자 투두리스트를 무한 생성하다가 나혼자 내가 만들고싶은 토이프로젝트를 만들었다. 그리고 처음으로 백엔드와 협업을 해보았다.
토이 프로젝트를 총 2번 진행을 하였다. 퀴즈를 맞추는 사이트를 만들어보기도 했고 버거킹 사이트를 클론코딩도 했다.
그 중에서도 HTTP 상태코드와 CORS 에러, 그리고 API 명세서에 대해서 배운 것이 가장 큰 것 같다.
HTTP 상태코드
- 1xx(정보) : 요청을 받았으며 프로세스를 계속 진행.
- 2xx(성공) : 요청을 성공적으로 받았으며 인식했고 수용.
- 3xx(리다이렉션) : 요청 완료를 위해 추가 작업 조치가 필요.
- 4xx(클라이언트 오류) : 요청의 문법이 잘못되었거나 요청을 처리할 수 없음.
- 5xx(서버 오류) : 서버가 명백히 유효한 요청에 대한 충족을 실패함.
HTTP 상태코드는 서버에서 클라이언트로 응답을 보낼 때 해당 응답의 상태를 표시하는 것이다.
200번대의 상태코드는 성공적인 응답을, 400번대의 상태코드는 클라이언트 오류를, 500번대의 상태코드는 서버 오류를 나타낸다. 이러한 상태코드들을 이해하고 활용하여, 여러 에러상태에서 대응을 하려고 했다.
CORS 에러
웹 브라우저에서 발생하는 보안 문제로, 서로 다른 도메인에서 오는 리소스를 사용하려고 할 때 발생한다. 이를 해결하기 위해서는 서버 측에서 헤더를 설정하여 허용된 도메인에서만 접근할 수 있도록 해주어야 한다.
API 명세서
API 명세서는 백엔드와 협업할 때 가장 중요한 문서다. API 명세서를 작성하면, 백엔드와 프론트엔드 개발자 간의 데이터를 주고받기위한 약속이고, 각자의 역할과 책임을 명확하게 알 수 있다.
하지만 ERD와 API 명세서의 차이점을 잘 모른채로 작성하다보니 중간중간 수정할 사항이 너무 많아졌다.
그래서 다음 프로젝트때는 기획단계에서 더 명확하고 상세하게 적어야겠다고 다짐했다.
또 가끔 API 명세서를 제대로 보지 않아서 생기는 문제점도 간혹 있었고 그로인해 낭비되는 시간이 너무 아깝다고 느껴졌다. 그래서 서로 이 부분에 대해서 의논을 하고 팀원들과 함께 이 명세서만큼은 꼭 지키자는 약속을 했다.
