👩🏫 오늘의 출석
❓스물세 번째, 9 to 9을 해 본 소감❓
오랜만에 Tistory 스킨을 커스텀 한다고 html, CSS 등을 만져보는데 너무 재미있었다. 그냥 다른 사람이 작성해 둔 코드를 가지고 와서 조금만 수정해서 사용하는 건데도 중간중간 내 취향에 맞게 꾸밀 수 있어 진짜 시간 가는 줄 모르고 했다. velog를 쓸 땐 글을 작성할 때 할 수 있는 것이 조금 제한적이라고 느껴서 Tistory로 갈아탈까? 계속 고민하다가 어제 공부 내용을 좀 정리하며 글을 작성하고 싶다는 생각에 Tistory 계정만 만들어 두고 오늘 처음 작성해 봤는데 사실 velog와 크게 다르다는 생각은 안 들었다. 오히려 velog에 그새 적응이 되어서 Tistory를 velog 처럼 보일 수 있는 스킨을 찾았을 정도였다. 역시 각자의 장점이 확실한 것 같다.
📑오늘 학습한 내용
🧩오늘의 알고리즘 : 음양 더하기 🧩
문제 : 어떤 정수들이 있습니다. 이 정수들의 절댓값을 차례대로 담은 정수 배열 absolutes와 이 정수들의 부호를 차례대로 담은 불리언 배열 signs가 매개변수로 주어집니다. 실제 정수들의 합을 구하여 return 하도록 solution 함수를 완성해주세요.
제한사항
- absolutes의 길이는 1 이상 1,000 이하입니다.
- absolutes의 모든 수는 각각 1 이상 1,000 이하입니다.
- signs의 길이는 absolutes의 길이와 같습니다.
signs[i]가 참이면absolutes[i]의 실제 정수가 양수임을, 그렇지 않으면 음수임을 의미합니다.
class Solution {
public int solution(int[] absolutes, boolean[] signs) {
int answer = 0;
for (int i = 0; i < absolutes.length; i++) {
if (signs[i]) {
answer += absolutes[i];
} else {
answer -= absolutes[i];
}
}
return answer;
}
}🧩 오늘의 SQL : 입양 시각 구하기(1) 🧩
문제 : 보호소에서는 몇 시에 입양이 가장 활발하게 일어나는지 알아보려 합니다. 09:00부터 19:59까지, 각 시간대별로 입양이 몇 건이나 발생했는지 조회하는 SQL문을 작성해주세요. 이때 결과는 시간대 순으로 정렬해야 합니다.
SELECT HOUR(DATETIME), COUNT(*)
FROM ANIMAL_OUTS
WHERE HOUR(DATETIME) >= 9 AND HOUR(DATETIME) < 20
GROUP BY HOUR(DATETIME)
ORDER BY HOUR(DATETIME)HOUR
WHERE HOUR(DATETIME) ⇒ 이렇게 작성해야 함
WHERE HOUR ⇒ 이런 식으로 작성 불가
오전에는 어제 새로 만든 Tistory에 개인 과제 관련 내용들을 정리하면서 과제 제출 시 생각해야 하는 부분에 대해 작성했다. 그리고 과제 제출하고 Tistory 스킨을 꾸미는 것에 꽂혀서 이것저것 찾아보고 내 마음에 들게 html을 수정하며 시간을 보내고 Spring 1주 차 강의를 들으며 급하게 넘어갔던 부분들을 하나씩 다시 보면서 조금 자세하게 공부하며 시간을 보냈다.
❣️Spring 입문 주차 개인과제
1. 수정, 삭제 API의 request를 어떤 방식으로 사용하셨나요? (param, query, body)
⇒ body 사용 : 수정 및 삭제 API의 요청 데이터는 @RequestBody를 사용하여 JSON 형식으로 전달하도록 함.
2. RESTful 한 API를 설계하셨나요? 어떤 부분이 그런가요? 어떤 부분이 그렇지 않나요?
- RESTful 한 부분
리소스 경로 설계 : /api/schedules로 일정을 나타내며, RESTful 한 경로 설계
HTTP 메서드 사용
POST /api/schedules: 새로운 일정을 생성
GET /api/schedules: 모든 일정을 조회
GET /api/schedules/{id}: 특정 일정을 조회
PUT /api/schedules/{id}: 특정 일정을 수정
DELETE /api/schedules/{id}: 특정 일정을 삭제
HTTP 상태 코드 사용
상태 코드 사용(예: 201 Created, 200 OK, 404 Not Found 등)은 클라이언트에게 요청의 결과를 명확히 전달함
- RESTful하지 않은 부분
세부적인 RESTful 요소 부족
상태 코드와 함께 더 구체적인 응답 메시지를 제공하지 않을 수 있음
예외 처리 및 에러 응답이 자세히 다루어지지 않았음
데이터 검증 및 보안
데이터 검증(예: 입력 데이터 유효성 검사)과 보안 조치(예: 비밀번호 해싱 및 보호)가 코드에서 명확히 다루어지지 않음.
결론
⇒ 기본적인 RESTful 설계 원칙을 따르고 있지만, 몇 가지 추가적인 개선 사항을 통해 더 완전한 RESTful API를 만들 수 있다.
3. 적절한 관심사 분리를 적용하셨나요? (Controller, Service, Repository)
Controller: HTTP 요청을 처리하고, 클라이언트에게 응답을 반환하는 역할을 잘 수행하고 있으며, 비즈니스 로직을 서비스 계층에 위임하고 있음
Service: 비즈니스 로직을 처리하며, 데이터베이스 접근은 리포지토리 계층에 위임하고 있고 데이터 변환 로직도 포함하고 있음
Repository: 데이터베이스 접근 로직을 담당하고 있으며, JpaRepository를 통해 기본적인 CRUD 작업을 수행함
DTO 및 Request Classes: 데이터 전송 및 요청 데이터를 캡슐화하여 관심사를 분리하고 있음
⇒ 따라서 적절한 관심사 분리를 적용하고 있고, 각 계층이 자신의 역할을 충실히 수행하며, 서로의 역할을 침범하지 않는다.
4. API 명세서 작성 가이드라인을 검색하여 직접 작성한 API 명세서와 비교하여 차이점을 설명해 주세요.
⇒ 반환 데이터가 없다. 이 부분은 계속 찾아보고 시도를 하는 중인데 postman을 사용해서 반환 데이터까지 제대로 확인을 했는데 이걸 documentation에서 어떻게 test 반환 결과를 나타내는지 모르겠어서 아직 url 상에서는 반환 결과를 보여주지 못했다. 이 부분에 대해서 추가적인 수정을 위해 계속 알아보는 중이다.
