Section1 실습과제 Day 1
[WAS 실습]
Day1
Achievement Goal
- API 문서 작성
Bare Minimum
- 관계형 데이터베이스를 위한 데이터를 모델링하고, API 문서화를 진행한다.
Advanced
- 주어진 기능 명세 외 필요하다고 생각되는 명세를 추가로 개발한다.
우리팀은 LMS (학습 관리 시스템)을 주제로 만들게 되었다.
1. 데이터베이스 설계, ERD 다이어그램 제작
DB 다이어그램을 사용해서 ERD 다이어그램을 만들었다
dbdiagram.io - Database Relationship Diagrams Design Tool
dbdiagram.io
LMS 애플리케리션의 조건
- 사용자는 모든 수업을 조회할 수 있다
- 사용자는 특정 분류의 수업을 조회할 수 있다(예: 강의자/ 수업명 / 수업코드 등)
- 사용자는 수업을 수강신청 할 수 있다
- 사용자는 모든 수강중인 수업을 조회할 수 있다
- 사용자는 이메일 정보와 같은 개인정보를 변경할 수 있다
- 사용자의 타입이 강의자일 경우 새로운 수업을 생성할 수 있다
- 사용자는 수업에 대한 수강신청을 취소 할 수 있다
사용자의 정보를 담는 users 테이블
강의 정보를 담는 class 테이블
사용자가 수강중인 강의 목록을 담기 위한 join 테이블인 user_class 테이블
이렇게 세개의 테이블을 만들었다.
users 테이블과 user_class는 한 사용자가 여러 강의를 들을 수 있으므로 1:n 관계
class 테이블과 user_class는 한 강의에 여러 학생이 들을 수 있으므로 1:n 관계
users 테이블과 class는 한 강의자가 여러 강의를 만들 수 있으므로 1:n 관계이다.
수정이 필요한 부분*
users 테이블에 type 을 'S', 'T'로 학생과 강의자를 구분하였다.
우리팀은 강의 자료를 보고 users 테이블 하나만 작성해야하는 줄 알고 한 테이블에 학생과 교수들을 다 담았다.
근데 발표때 보니 디비 형식은 우리 맘대로 작성해도 되더라고용?
그래서 디비 관리 목적에도 맞게 users 테이블은 students와 teachers 이런식으로 두개의 테이블로 나누는게 나을 것 같다.
아마 내일 Day2 과제를 진행하면서 또 테이블 구조가 바뀌지 않을까 싶다
2. API 문서 제작
이렇게 위 애플리케이션에 조건에 맞는 API 명세를 작성하였다.
sheety를 사용하기 위해서 구글 시트에 테이블 별 데이터를 작성해보았다.
- GET /class
{
"class": [
{
"id": 2,
"title": "네트워크 기초",
"teacher": "투명인간",
"code": 100,
"teacher_id": 4
},
{
"id": 3,
"title": "데이터베이스",
"teacher": "투명인간",
"code": 200,
"teacher_id": 4
},
{
"id": 4,
"title": "REST API",
"teacher": "도라에몽",
"code": 300,
"teacher_id": 5
},
{
"id": 5,
"title": "리눅스",
"teacher": "도라에몽",
"code": 400,
"teacher_id": 5
}
]
}
- GET /class?teacher_id=4
{
"class": [
{
"id": 2,
"title": "네트워크 기초",
"teacher": "투명인간",
"code": 100,
"teacher_id": 4
},
{
"id": 3,
"title": "데이터베이스",
"teacher": "투명인간",
"code": 200,
"teacher_id": 4
}
]
}
- GET /class?title='네트워크 기초'
{
"class": [
{
"id": 2,
"title": "네트워크 기초",
"teacher": "투명인간",
"code": 100,
"teacher_id": 4
}
]
}
- GET /class?code=100
{
"class": [
{
"id": 2,
"title": "네트워크 기초",
"teacher": "투명인간",
"code": 100,
"teacher_id": 4
}
]
}
- GET /user_class?studenet_id=1
{
"user_class": [
{
"uc_id": 1,
"student_id": 1,
"class_id": 1,
"id": 2
},
{
"uc_id": 2,
"student_id": 1,
"class_id": 2,
"id": 3
}
]
}
- POST /user_class
{
"student_id": 1,
"class_id": 1
}
- POST /class
{
"title": "알고리즘",
"teacher": "투명인간",
"code": 600,
"teacher_id": 4
}
- PUT /user?id=1
{
"name": "길경서",
"email": "gs@codestates.com",
"phone": "01000000000"
}
API 명세를 작성할때 엔드포인트와 쿼리에 신경을 써서 작성했는데,
엔지니어 분이
"POST 나 PUT, DELETE 메소드를 사용할 경우의 해당 사용자만이 조작하도록 인증하는 과정 Request Header에 추가해봐라"
라는 피드백을 주셨다.
그래서 Request Header에 user.id 를 넣어야하나? 뭘까낭? 도대체 뭐야? 하고 있었는데
Authorozation : token 이 정답이었다.ㅋㅋㅋㅋ
HTTP는 보약이 취약하기 때문에 path에 사용자 정보를 담으면 위험하기 때문에 인증토큰을 사용하는 것은 기본인데,
왜 이것까지 생각을 못해쓰깡~?
3. Advanced 활동
advanced로 api 명세를 추가로 작성하고, swagger를 사용하라는데
swagger 는 YAML을 API 문서로 변환해주는 프로그램이다.
혼자서 한번 작성해 보았당.
Build, Collaborate & Integrate APIs | SwaggerHub
app.swaggerhub.com
음 오류가 난당..
왜..?
일단 감은 잡았으니 팀원들이랑 같이 해봐야겠당
저번에 HTTP 를 배울때 pair 활동을 하면서 yaml을 작성했었는데 이걸 솔직히 왜 만드나 했다.
지금도 같은 생각..? 이걸 정말 실무에서 쓰나..?
advanced 활동으로 api 명세를 추가로 만들어보라는데 이건 패쓰~~ㅎㅎ
오늘 학습의 회고
부트캠프 코드스테이트 Devops 수업을 들은지 한달이 되었다.
블로그 정리해야지.. 해야지.. 하고 한달이 지나감
section1이 끝나가면서 실습과제에 들어가게 되면서 이제는 정말 복습 겸 정리를 해야겠다고 다짐했다.
수업끝나고 저녁먹고 운동, 그리고 블로그 정리하는 습관을 들이자!
오늘은 처음으로 팀과제를 하게되었다.
이때까지 배웠던 수업을 내가 너무 만만하게 봤던걸까?
데이터베이스 설계부터 쉽지 않았다.
하지만 여차저차 해결하면서 수업을 이해한것 같다.
나름 목표에 맞게 설계한 것 같다.
내일은 Day2 과제를 진행한다고한다.
이제 설계한 DB를 실제로 만들고 프로젝트를 만들고 연동하면서 서버를 구현하는 것 같다.
무서우면서도 좀 기대된당
팀활동이 처음 시작 과정은 어렵게 느껴지지만 같이 해결하는 성취감이 제법 크다.
우리팀은 참 분위기가 좋기 때문에 항상 재밌게 공부하것 같다.
이번에 과제를 진행하면서 직접 수행하면 복습도 될 것 같다.
이제 감 좀 잡았으니 내일은 조금 수월하게 과제를 할 수 있지 않을까?😊
