퇴사 결정하길 잘했다!!!!!
다음주부터 코딩에 전반적으로 집중하게 되는데 그렇게 되면 시간이 굉장히 많이 소요될 거라는 이야기에 퇴사 결정을 내린 얼마 전의 내가 몹시 현명하다고 느껴졌다. 아니나다를까, 생각보다 나의 설계력이 그렇게 완전하지 않다는 걸 이번에 API 및 DB 명세서를 작성하면서 느꼈기 때문에!! 아, 그래서 내 이력서들이 다 그렇게 우수수 퇴짜를 맞았구나? 하는 깊은 깨달음을 얻으며 API와 oAuth의 개념 공부부터 다시 해야겠구나 했다.
그래서 오늘 수업에서 새삼 정리된 개념부터 짚고 넘어가야겠다.
API의 정의
API는 미들웨어와 비슷한 개념인 모양이다. 결국에는 같은 역할을 하는 거 같은데 router라고도 하고 link라고도 하고 controller mapping이라 하기도 하며 servlet이라고도 불린 걸 봤다. 내가 경험했던 그 모든 것들이 결국에는 API를 의미한 거 같다. 그래서 요는 리소스의 전달을 하기 위한 명시적인 호출 경로같은 기능을 한다는 점은 정리되는 거 같다.
REST API와 method
요즘에 다들 그래서 REST 노래를 부르던데? 영원히 쉬고 싶은 개발자의 속마음 같은 거라도 되나??
결국에는 그게 뭐가 됐든 API를 알아보기 쉽게 써서 잘 이용하자, 뭐 이런 취지인 거 같다. 새삼 정리된 개념은 이게 아니긴 한데 형식상 왠지 써줘야 할 거 같았다.
http method는 크게 네가지로 이야기된다.
- get: read
- post: create resource
- put: update all
- delete: delete
언제부터인가 모든 개념을 CRUD로 정리하게 된 나머지 나에게 http method도 역시나 이렇게 받아들여진다.
그리고 여기에 오늘의 가장 중요한 개념 정리가 있다.
- patch: edit
put의 경우 가지고 오는 단위의 전체가 수정되는 개념이다. 반면 patch는 부분적으로 수정된다는 점이 눈여겨 봐야 하는 점이 된다.
그러고 보면 fetch라는 개념도 존재하는데, 이건 또 나중에 찾아봐야겠다.
그리고 request body, response body와 endpoint 등의 개념에 대해서도 계속 혼란이 있었는데 수업 때 질문하고 다른 사람들의 예시를 보며 정리할 수 있었다. 어떻게 정리됐는가를 문서로 쓰고 싶지만... 사실은 이동 중에 듣느라 제대로 못 들었던 부분이 너무 많아 아쉽다. 핵심은 API의 설계가 resource 단위로 이루어져야 하며 request body와 response body는 front에서 back으로 요청을 보냄에 있어 필요한 내용만 있으면 된다는 점 정도다.
비동기 요청을 늘 하면서 http니 ajax니 xhr이니 매일같이 헷갈렸는데 오늘 강의로 아무튼 어떻게 정리가 된 듯도 하다(아닌듯도하다.).
