0. 요구사항 분석
A. 일정 생성
- 고유 식별자(ID) → 자동 생성
- 작성자명
- 비밀번호
- 할 일
- 최초 작성일 : 날짜와 시간을 모두 포함한 형태
- 수정일 : 날짜와 시간을 모두 포함한 형태
* 최초 입력 시, 수정일은 작성일과 동일
B. 전체 일정 조회
- 수정일 기준 내림차순으로 정렬하여 조회
C. 일정 검색
- 수정일 (형식 : YYYY-MM-DD)
- 작성자명
* 조건 중 한 가지만을 충족하거나, 둘 다 충족하지 않을 수도, 두 가지를 모두 충족할 수 있음
D. 선택한 일정 조회
- 선택한 일정 단건의 정보 조회 가능
- 일정의 고유 식별자(ID)를 사용하여 조회
E. 선택한 일정 수정
- 할 일, 작성자만 수정 가능
- 서버에 일정 수정을 요청할 때, 비밀번호를 함께 전달
- 최초 작성일은 변경 불가
- 수정일은 수정 완료 시, 수정한 시점으로 변경
F. 선택한 일정 삭제
- 서버에 일정 삭제를 요청할 때, 비밀번호를 함께 전달
G. 작성자와 일정의 연결
- 설명
- 동명이인의 작성자가 있어 어떤 작성자가 등록한 ‘할 일’인지 구별할 수 없음
- 작성자를 식별하기 위해 이름으로만 관리하던 작성자에게 고유 식별자를 부여합니다.
- 작성자 테이블을 생성하고 일정 테이블에 FK를 생성해 연관관계를 설정해 봅니다.
- 조건
- 작성자는 이름 외에 이메일, 등록일, 수정일 정보를 가지고 있습니다.
- 작성자의 정보는 추가로 받을 수 있습니다. (조건만 만족한다면 다른 데이터 추가 가능)
- 고유 식별자를 통해 작성자를 조회할 수 있도록 기존 코드를 변경합니다.
- 작성자의 고유 식별자가 일정 테이블의 외래키가 될 수 있도록 합니다.
- 작성자는 이름 외에 이메일, 등록일, 수정일 정보를 가지고 있습니다.
H. 페이지네이션
- 설명
- 많은 양의 데이터를 효율적으로 표시하기 위해 데이터를 여러 페이지로 나눕니다.
- 페이지 번호와 페이지 크기를 쿼리 파라미터로 전달하여 요청하는 항목을 나타냅니다.
- 전달받은 페이지 번호와 크기를 기준으로 쿼리를 작성하여 필요한 데이터만을 조회하고 반환
- 많은 양의 데이터를 효율적으로 표시하기 위해 데이터를 여러 페이지로 나눕니다.
- 조건
- 등록된 일정 목록을 페이지 번호와 크기를 기준으로 모두 조회
- 조회한 일정 목록에는 작성자 이름이 포함
- 범위를 넘어선 페이지를 요청하는 경우 빈 배열을 반환
- Paging 객체를 활용할 수 있음
1. 기능 설계
- 접속하자마자 전체 일정 조회하기
- GET API 사용해서 일정 목록 불러오기
- 일정 생성하기
- POST API 사용해서 일정 신규 생성하기
- 생성된 일정 반환
- 선택한 일정 조회하기
- GET API 사용해서 선택한 일정 불러오기
- 사용자가 선택한 일정이 DB에 존재하는지 확인
- 선택한 일정 수정하기
- PUT API 사용해서 일정 내용 변경하기
- 사용자가 선택한 일정이 DB에 존재하는지 확인
- 서버에 일정 수정을 요청할 때 비밀번호를 함께 전달
- 비밀번호가 일치하는지 확인
- 해당 일정 내용 변경
- 선택한 일정 삭제하기
- DELETE API 사용해서 일정 삭제하기
- 사용자가 삭제하려는 일정이 DB에 존재하는지 확인
- 서버에 일정 삭제를 요청할 때 비밀번호를 함께 전달
- 비밀번호가 일치하는지 확인
- DB에서 해당 일정 삭제
- 일정 검색하기
- GET API 사용해서 일정 검색하기
- 사용자가 검색한 키워드에 해당하는 일정이 DB에 존재하는지 확인
- 일치하는 일정 반환
2. API 명세서
공통 요청(Request) 및 응답(Response) 형식
- API 요청 및 응답에 사용하는 데이터 형식은 ‘applicatoin/json’으로 제한하였습니다.
Content-Type: application/json
- 선택한 일정 수정과 삭제는 해당 일정의 고유 식별자를 반환합니다.
- -1: 해당 스케줄은 DB에 존재하지 않음
- -2: 비밀번호 불일치
- DB에 저장된 날짜 관련 데이터는 모두 UTC로 저장되어 있습니다.
API 명세서
기능 | Method | URL | Request | Response | Return |
일정 생성 | POST | /api/scheduler | RequestBody | 생성된 일정 정보 | SchedulerResponseDto |
전체 일정 조회 | GET | /api/scheduler | - | 모든 일정 정보 | List<SchedulerResponseDto> |
일정 검색 | GET | /api/scheduler/search | RequestParam | 검색된 일정 정보 | List<SchedulerResponseDto> |
선택한 일정 조회 | GET | /api/scheduler/{schedulerId} | PathVariable | 선택한 일정 정보 | SchedulerResponseDto |
선택한 일정 수정 | PUT | /api/scheduler/{schedulerId} | PathVariable, RequestBody | 수정된 일정 ID | Long |
선택한 일정 삭제 | DELETE | /api/scheduler/{schedulerId} | PathVariable, RequestBody | 삭제된 일정 ID | Long |
A. 일정 생성
- RequestBody
{
"writer": "스파르타",
"password": "sparta24",
"todo": "공부하기"
}
- ResponseBody
{
"id": 1005,
"writer": "스파르타",
"todo": "공부하기",
"createdDate": "2024-10-04T00:17:40.000+00:00",
"updatedDate": "2024-10-04T00:17:40.000+00:00"
}
B. 전체 일정 조회
- ResponseBody
[
{
"id": 100,
"writer": "스파르타",
"todo": "공부하기",
"createdDate": "2024-10-04T00:17:40.000+00:00",
"updatedDate": "2024-10-04T00:17:40.000+00:00"
},
{
"id": 3,
"writer": "새벽이",
"todo": "Bling Bling is my name",
"createdDate": "2024-10-03T12:42:15.000+00:00",
"updatedDate": "2024-10-03T22:42:15.000+00:00"
},
{
"id": 1004,
"writer": "베르",
"todo": "간식 먹기",
"createdDate": "2024-09-28T15:53:07.000+00:00",
"updatedDate": "2024-10-03T19:44:30.000+00:00"
},
{
"id": 7777777,
"writer": "하늘",
"todo": "행복하자~ 아프지망고",
"createdDate": "2024-10-03T15:57:54.000+00:00",
"updatedDate": "2024-10-03T15:57:54.000+00:00"
},
{
"id": 2,
"writer": "스티븐 잡스",
"todo": "일하자",
"createdDate": "2024-09-29T15:53:07.000+00:00",
"updatedDate": "2024-10-01T23:11:22.000+00:00"
}
]
C. 일정 검색
- @RequestParam(required = false) String writer: 검색하려는 작성자
- @RequestParam(required = false) Timestamp updatedDate: 검색하려는 수정일
D. 선택한 일정 조회
- @PathVariable: 선택한 일정의 고유 식별자
- ResponseBody
{
"id": 1005,
"writer": "스파르타",
"todo": "공부하기",
"createdDate": "2024-10-04T00:17:40.000+00:00",
"updatedDate": "2024-10-04T00:17:40.000+00:00"
}
E. 선택한 일정 수정
- @PathVariable: 선택한 일정의 고유 식별자
- RequestBody
{
"writer": "스파르타",
"todo": "공부도 하고~ 쉬기도 하고~ 운동도 하고~ 룰루랄라~ 울랄라~~"
}
- Return: 수정된 일정의 고유 식별자
F. 선택한 일정 삭제
- @PathVariable: 선택한 일정의 고유 식별자
- Return: 삭제된 일정의 고유 식별자
3. ERD (Entity Relationship Diagram)
1) 필수 기능 ( ~ Lv 3)
SCHEDULER의 고유 식별자(ID)
- SCHEDULER의 고유 식별자는 정수 타입으로 저장되며, 스케줄을 생성할 때 자동 생성됩니다.
작성 가능한 스케줄의 갯수를 설정하지 않았으므로, 최대한 많은 글을 허용할 수 있게 BIGINT로 설정하였습니다.
작성자명
- 작성자명은 NULL을 허용하지 않으며 최대 10자까지 허용합니다.
- 이때 가능한 입력은 이모지를 제외한 영어와 한글, 특수 기호입니다.
가장 큰 3바이트의 한글인 경우를 고려하여 크기를 30으로 설정하였습니다.
비밀번호
- 비밀번호는 NULL을 허용하지 않으며 최대 20자까지 허용합니다.
- 이때 모든 입력은 영어나 특수 기호로 입력받습니다.
모든 입력은 영어 및 특수 기호로 1바이트입니다. 따라서 크기를 20으로 설정하였습니다.
할 일
- 할 일은 최대 100글자까지 허용합니다.
`VARCHAR(400)`으로 설정한 이유는 먼저 VARCHAR는 가변 길이 문자열을 저장하여 메모리를 효율적으로 사용하기 때문입니다. 크기를 400으로 설정한 이유는 4바이트인 이모지로만 이루어진 경우도 포함하기 위함입니다. 이런 설정은 다양한 문자와 기호를 수용할 수 있도록 하여 데이터의 유연성을 높입니다.
최초 작성일 및 수정일
- 날짜와 시간을 모두 포함한 형태의 데이터
날짜와 시간을 모두 포함한 형태의 데이터이어야 하므로, DATETIME과 TIMESTAMP를 사용할 수 있습니다.
`DATETIME` 은 1000-01-01 00:00:00 UTC 부터 9999-12-31 23:59:59 UTC 까지 표시할 수 있지만 8바이트입니다.
`TIMESTAMP` 는 1970-01-01 00:00:00 UTC 부터 2037-01-19 03:14:07 UTC 까지만 표시할 수 있지만 4바이트입니다.
현재 프로젝트를 진행하는 시점은 2024년이고 향후 10년을 고려해도 2034년까지의 날짜가 필요하므로, 더 적은 메모리를 필요로 하는 TIMESTAMP를 이용하였습니다.
TIMESTAMP은 행이 삽입되거나 업데이트될 때 자동으로 현재 시간을 기록할 수 있어 최초 작성일 및 수정일 관리에 용이합니다. 또한 UTC 기준으로 저장되어 시간대가 서로 다른 경우에도 일관된 시간 기록을 유지할 수 있습니다. 데이터베이스가 설정된 시간대에 따라 자동 변환되므로, 애플리케이션에서 다양한 시간대를 다루기 용이합니다.
따라서 TIMESTAMP가 메모리 효율성, 자동 시간 기록, 시간대 처리 측면에서 이번 프로젝트에 적합합니다.
2) 도전 기능 (Lv 4)
추후 WRITER 추가하여 진행할 예정
'🏕 내일배움캠프 > [Assignment] Ch3-1' 카테고리의 다른 글
[회고] 문제 발생 및 해결, 느낀 점 (0) | 2024.10.04 |
---|