멘토링 일정 잡음(내일)
약 먹어서 헤롱헤롱 함.
REST API
북 히스토리 관련해서 고민
-
post요청만 보내면 서버에서 히스토리가 없으면 생성하고, 있으면 조회수를 업데이트
-
post요청 보내서 히스토리 없으면 생성하고 없으면 fasle 응답, 그럼 프론트에서 다시 patch요청 보내서 count 업데이트
1은 프론트 구현이 간단하지만 rest 원칙에 어긋남.
2는 rest 원칙에 부합하지만, 프론트 구현 코드가 많아지고 요청이 여러 번 발생
이에 관한 GPT 답변
두 접근 방식 모두 특정 상황과 요구사항에 따라 유효할 수 있으며, 각각의 장단점이 있습니다. 선택은 주로 API 설계 원칙, 유지보수성, 클라이언트와 서버 간의 상호작용 복잡성에 따라 달라집니다.
1. 단일 POST 요청으로 처리
장점:
단순성: 프론트엔드에서 단일 요청으로 모든 작업을 처리할 수 있어 개발 및 디버깅이 간단합니다.
효율성: 네트워크 트래픽과 서버 부하를 줄일 수 있습니다.
단점:
REST 원칙 위반: 이 방법은 RESTful 원칙에 완전히 부합하지 않습니다. POST는 일반적으로 새 리소스 생성에 사용되며, 기존 리소스를 업데이트하는 데는 PUT 또는 PATCH가 사용됩니다.
확장성 제한: 향후 추가적인 로직이 필요할 경우, 단일 엔드포인트에 모든 로직을 유지하는 것은 관리 및 확장성 측면에서 어려울 수 있습니다.
2. POST와 PATCH 요청 분리
장점:
RESTful: 이 방법은 REST 원칙을 더 잘 따르며, 각 HTTP 메서드의 목적에 맞게 사용됩니다.
명확한 API 설계: API의 동작이 명확하고 예측 가능합니다.
단점:
복잡성 증가: 프론트엔드는 응답에 따라 추가 요청을 해야 하므로, 로직이 복잡해집니다.
추가 요청 필요: 네트워크 트래픽과 서버 부하가 증가할 수 있습니다.
결론
일반적으로 RESTful 원칙을 준수하는 것이 장기적으로 유지보수성과 확장성 측면에서 이점을 제공합니다. 그러나, 단순한 애플리케이션에서는 첫 번째 방법의 단순성과 효율성이 더 유리할 수 있습니다. RESTful 원칙을 엄격하게 준수할 필요가 없는 경우, 특히 작은 프로젝트나 초기 프로토타이핑 단계에서는 단일 요청 방식이 더 편리할 수 있습니다. 결국 선택은 프로젝트의 요구사항, 팀의 선호도, 기술적 제약사항을 고려하여 결정되어야 합니다.
결정
우선 초기 프로토타입 구현 시기이니 방법 1로 빠르게 구현
추후 프론트엔드 안정화되면 분리
API Design
https://www.yes24.com/Product/Goods/124127840
REST
- 요청-응답 모델 사용
- stateless
- 모든 것을 자원으로 간주하며, 각 자원은 URI에 의해 식별
- 자원에 대한 요청을 처리(메서드)
리소스를 메서드로 처리하는 것
기본 상태 코드
101 웹소켓 프로토콜로 업그레이드
200 요청 성고
201 요청 결과 새 자원 생성
301 요청한 URL에 해당하는 자원이 새로운 URL로 영구적으로 이동
403 권한 부족
404 요청한 자원이 존재하지 않음
504 프록시, 게이트웨이 백엔드 도착 못하고 타임 아웃
미디어 타입(MIME)
HTTP는 멀티미디어 프로토콜
여러 가지 형식의 요청과 응답 처리 가능
오가는 데이터 형식 알려주기 위해 Content-Type헤더에 미디어 타입 명시
(이메일 표준에서 시작됨)
타입과 서브타입으로 구분 됨.
주요 미디어 타입
text/html
text/csv
image/png
application/json
application/xml
메서드
GET, DELETE는 요청 본문이 허용되지 않음.
GET 요청은 설정에 따라 캐싱을 활용할 수 있음.
인증 vs 인가
인증: 누구인지 증명
인가: 특정 자원 접근 권한 허가
API 설계
API 설계자는 서버가 아니라 클라이언트의 관점에서 API를 바라봐야 함.
사용자 스토리
- 나는 <역할>로서 <기능>을 할 수 있고, 그 결과 <보상>을 받는다.
- <사전 조건>이 주어지면 나는 <기능>을 할 수 있다.
예)
- 반려동물 주인으로서 나는 구인 공고를 올릴 수 있고, 그 결과 휴일에 자유로운 시간을 보낼 수 있다.
- 구인 공고가 올려졌으므로 구인 공고 상태를 확인할 수 있다.
