mockAPI로 CRUD를 구현하며 배운 것들
오늘은 mockAPI를 이용해서 맛집 목록 CRUD를 구현했다.
기능을 만드는 과정에서 프론트와 백엔드 흐름, API, HTTP Method 같은 개념을 조금 더 구체적으로 이해할 수 있었다.
1. 프론트와 백엔드는 역할이 다르다
오늘 작업하면서 가장 크게 느낀 건
프론트는 보여주는 역할, 백엔드는 저장하고 처리하는 역할이라는 점이었다.
프론트는 입력 폼, 버튼, 카드 목록처럼 사용자가 보는 화면을 만든다.
반면 사용자가 입력한 데이터를 저장하고, 다시 불러오고, 수정하고, 삭제하는 일은 서버가 담당한다.
오늘 사용한 mockAPI는 실제 백엔드 서버를 대신해주는 가짜 서버 역할을 했다.
2. API는 프론트와 백엔드의 약속이다
오늘 구현하면서 사용한 API는 이런 형태였다.
POST /placesGET /placesPUT /places/:idDELETE /places/:id
이 과정을 통해 API는 단순한 주소가 아니라,
프론트와 백엔드가 서로 어떤 요청과 응답을 주고받을지 정해둔 약속이라는 걸 이해하게 됐다.
3. HTTP Method는 동작의 종류를 나타낸다
오늘 CRUD를 구현하면서 Method의 역할이 확실해졌다.
POST: 생성GET: 조회PUT: 수정DELETE: 삭제
같은 /places라는 경로라도 Method가 다르면 전혀 다른 동작이 된다.
이 점이 오늘 가장 크게 체감된 부분 중 하나였다.
4. API 명세서가 왜 필요한지 이해했다
오늘 작업하면서 프론트 입력 필드와 서버 필드가 다를 수 있다는 걸 직접 경험했다.
예를 들어:
- 프론트:
location - 서버:
address
이럴 때 API 명세서가 없으면 프론트와 백엔드가 서로 다른 상상을 하게 된다.
그래서 API 명세서는
이 API가 어떤 요청을 받고 어떤 응답을 주는지 적어둔 공식 문서라는 걸 더 잘 이해하게 됐다.
5. 데이터가 안 보인다고 다 오류는 아니다
초반에는 카드가 안 보이면 무조건 코드가 잘못된 줄 알았다.
그런데 실제로는 요청이 성공했지만 응답이 빈 배열([])이라 카드가 안 뜨는 경우도 있었다.
즉, 문제를 볼 때는
- Console
- Network
- Response
를 함께 보면서
오류인지, 정상인데 데이터가 없는 상태인지 구분해야 한다는 걸 배웠다.
6. 수정과 삭제에서는 id가 중요하다
등록과 조회만 할 때는 크게 의식하지 않았는데, 삭제와 수정 기능을 만들면서 id가 왜 중요한지 확실히 알게 됐다.
삭제와 수정은 특정 데이터 하나를 정확히 식별해야 하기 때문에
각 데이터의 id가 꼭 필요했다.
이 경험을 통해 id는 단순 번호가 아니라
데이터를 구분하는 핵심 키라는 걸 이해하게 됐다.
마무리
오늘 mockAPI로 CRUD를 구현하면서 단순히 기능 하나를 만든 게 아니라,
웹 서비스의 기본 흐름을 실제로 경험할 수 있었다.
정리하면 오늘 배운 핵심은 이렇다.
- 프론트는 보여주고, 백엔드는 저장하고 처리한다
- API는 프론트와 백엔드의 약속이다
- HTTP Method는 동작의 종류를 나타낸다
- API 명세서는 협업과 연결을 위해 필요하다
- 데이터가 안 보인다고 다 오류는 아니다
- 수정과 삭제에는
id가 핵심이다
오늘 작업 덕분에 프론트와 백엔드가 어떻게 연결되는지 조금 더 선명하게 보이기 시작했다.
