유스케이스 다이어그램 및 RESTful한 API설계(Param vs Query vs Body)

💡 오늘의 학습 키워드

- 개인과제 -
유스케이스 다이어그램
API 명세서 작성
GET vs POST
Param vs Query vs Body
RESTful한 API 설계

---

 

유스케이스 다이어그램

: 사용자랑 시스템사이에 관계를 나타내는 것

* 구성 요소

1. 시스템(System)
: 만들고자 하는 프로그램

시스템의 표현방법	예시

 

2. 액터(Actor)
: 시스템의 외부에 있고 시스템과 상호작용을 하는 사람, 시스템

액터의 표현방법	예시

 

3. 유스케이스(Usecase)
: 사용자 입장에서 바라본 시스템의 기능

유스케이스의 표현방법	예시

 

4. 관계(Relation)
: 액터와 유스케이스 사이의 의미있는 관계를 나타냄

연관관계(Association) : 유스케이스와 액터 간의 상호작용이 있음을 표현
포함관계(Include) : 하나의 유스케이스가 다른 유스케이스의 실행을 전제로 할 때 형성되는 관계
확장관계(Extend) : 확장 기능 유스케이스와 확장 대상 유스케이스 사이에 형성되는 관계
일반화 관계(Generalization) : 유사한 유스케이스 또는 액터를 모아 추상화한 유스케이스 또는 액터와 연결시켜 그룹을 만들어 이해도를 높이기 위한 관계

 

* 참고한 블로그

(UML) 유스케이스 다이어그램 - Usecase Diagram

 

API 명세서 작성

: 블로그가 정리 더 잘되어 있어서 Pass

 

* 참고한 블로그

PostMan API 명세서 생성하기

 

GET vs POST

• GET
  • 데이터 요청 방식 : HTTP Request Message의 Header 부분의 url에 담겨서 전송
  • url 공간에 그대로 데이터가 담기기 때문에 보낼 수 있는 데이터 크기가 제한적이며 보안의 측면을 고려해야 함
• POST
  • 데이터 요청 방식 : Body 부분에 데이터를 담아 전송
  • GET과 비교하여 제한적인 크기, 보안의 측면에서 나을 수 있음(보안면은 암호화를 따로 하지 않는다면 비슷)
  • 언제 사용? 서버의 값이나 상태 등을 변경하기 위해 사용 ex) 게시글 작성

 

* 참고한 블로그

[Web] REST API 란? ( GET과 POST의 차이 )

 

Param vs Query vs Body

• Param(Path Parameter)
  • 용도 : 주로 특정 리소스나 객체를 식별하는 데 사용
  • 예시 : /users/{userId}에서 {userId}부분이 param이다. 사용자의 고유 ID를 지정하여 특정 사용자의 정보를 요청
  • 특징 : URL 경로의 일부분으로 포함되며, 각 리소스를 구분하는 데 핵심적인 역할을 한다.
  • UPDATE / DELETE 에서 주로 사용
• Query(Query String)
  • 용도 : 필터링, 정렬, 페이지네이션 등의 추가적인 옵션을 제공할 때 사용
  • 예시 : /users?age=30&sort=name에서 age=30과 sort=name부분이 query이다. 30세 사용자들을 이름순으로 정렬하여 요청할 수 있음
  • 특징 : URL 끝에 ? 다음에 위치하며, 여러 개의 쿼리를 & 기호로 연결
  • 조건을 통한 조회 즉 GET에서 주로 사용
  • 종류
    • Ordering ex) GET /products?ordering=-id
    • Filtering ex) GET /products?price=3000&name=사과
    • Pagination ex) GET /products?offset=0&limit=100
    • Searching ex) GET /users?search=홍길동

* 이런 식으로 조건이 많으면(프론트에서 던져줘야 되는) Query를 사용 ex) 쿠팡

* 그렇지 않고 기본 베이스의 조회라면 param, query, body를 사용하지 않고 기본 URL사용 ex) GET /api/users

 

• Body
  • 용도 : 주로 POST난 PUT 요청에서 사용되며, 크고 복잡한 전송을 할 때 사용
  • 예시 : 사용자의 상세 정보를 생성하거나 수정할 때, {"name" : "John", "age" : 30} 같은 JSON 형태의 데이터를 body에 담아 보냄
  • 특징 : URL에 직접적으로 노출되지 않으며, 데이터의 양이 많거나 복잡한 경우에 적합

 

* 참고한 블로그

T.I.L #34 수정, 삭제 API의 request를 하는 방식 : param, query, body

 

RESTful한 API 설계

: URI 정보를 명확하게 표현해야 한다!

* URI(Uniform Resource Identifier) ? 해당 사이트의 특정 자원의 위치를 나타내는 유일한 주소

* HTTP Method ? HTTP request가 의도하는 action을 정의한 것

* Payloda ? HTTP request에서 server로 보내는 데이터(body)

 

• HTTP Method(GET, POST, PUT, DELETE)
  • GET : 조회 (받겠다)
  • POST : resource 생성(보내겠다)
  • PUT : resource 전체 갱신 (놓겠다 / 넣겠다)
  • DELETE : resource 삭제 (지정한 서버의 파일을 삭제하겠다)
• 명사를 사용 ex) GET /user/1 -> GET /users/1
• URI에 HTTP Method가 포함되서는 안된다
• URI에 동사가 포함되서는 안된다.
  ex) GET /user/show/1 -> GET /users/1
        POST insert/user/2 -> POST /users/2
• resouce 사이에 연관관계가 있는 경우
  ex) 리소스/고유ID/관계 있는 리소스
        GET /users/{user_id}/profile
• 파일의 경우 payload의 포맷을 나타내기 위한 파일 확장자를 URI에 포함시키지 않는다
  ex) GET user/1/proffile-photo.jpg -> GET user/1/proffile-photo
• URI는 / 구분자를 사용하여 자원의 계층 관계를 나타내는데 사용한다
• URI 마지막 문자로 /를 포함하지 않는다
  ex) GET users/prorfolios
• 불가피하게 URI가 길어지는 경우 - 를 사용하여 가독성을 높인다
• _는 사용하지 않는다
  URI 경로에는 대문자 사용을 피하고 있다

 

 

* 참고한 블로그

RESTful한 API 설계

 

---

오늘의 궁금증

• Q : PUT vs POST?

 

지난 날의 궁금증

• 아직 찾아보지 못 한 궁금증(더보기 ..Click!)

• Q : 참조는 reference인데 자바는 call by value로만 동작하는 것 아닌가?
• Q : wrapper클래스.. 그래서 무슨 기능들을 가지고 있는데?
• Q : Object.equals와 str.equals의 차이? // 요건 공식 문서를 찾아봐야겠어..
• Q : JDBC 이란?
• Q : ORM 이란?
• Q : 객체의 불변성에 대해 궁금...?

 

---

개인과제

 

• 과제 설명

나만의 일정 관리 서버 제작 : 일정 작성, 전체 일정 조회, 선택한 일정 조회/수정/삭제

이렇게 5가지 기능이 필수 구현 기능이었다.

예외발생 처리, Swagger 활용 & 파라미터 유효성 검사, null 체크 및 특정 패턴에 대한 검증 수행, 파일 업로드 다운로드, 테스트 코드 작성 이렇게 4가지가 추가 구현 기능이었지..

 

• 내가 만들지 못한 부분
  • 선택한 일정 수정
  • 선택한 일정 삭제

 

• 만들지 못한 이유에 대해

시간이 없어서.. 코드 작성은 과제 제출 2~3시간 전부터 작성을 시작했다.

유스케이스 다이어그램, API 명세서 작성, ERD를 작성하는 데에 너무 오랜 시간을 소비했다.

 

• 과제 제출 이후의 고촬

과제 제출 이후에 알게 된 것은 3단계 일정 조회를 나는 조건 조회이기에 query stirng을 사용하는 게 좋겠다는 생각에 그렇게 사용하였다. 하지만 query string은 많은 조건 예시로 쿠팡의 정렬과 같은 조건에서 사용한다는 것을 알았다.

그리고 과제 제출 이후 필수 기능 구현까지의 과제 해설을 보고 느낀 것은 나는 그냥 코드 상태?를 반환하지 않도록 코드를 작성했는데 과제 해설 영상은 Entity.ok().build() 이런 식으로 반환을 해주었다. 내가 공부했던 영상에서는 이렇게 하지 않아서 몰랐지만, 다음번에는 조금 더 알아보고 코드를 작성할 필요성을 느꼈다.

 

GitHub - ysy56/agendaAppServer: 개인과제 두 번째 : 나만의 일정 관리 앱 서버

 

---

오늘의 회고

• 12시간 중 얼마나 몰입했는가?

과제 제출 전까지는 빠짝 공부했다..

그럼에도 필수 구현 기능을 모두 하지는 못했지만ㅠ

 

• 오늘의 생각

param vs query vs body에 대해 생각해보게 되었다. 

그리고 아래의 블로그를 보면서 이런 상황에서는 param이 맞는 건지 아니면 query이 맞는 건지 고민하게 된다.

마지막으로 RESTful한 API 설계에 대해 더 고민하고 내가 작성한 API 명세서를 수정할 필요성을 느꼈다.

 

 

* 참고한 블로그

RESTful한 API 설계

 

• 내일 학습할 것은 무엇인지

네트워크 관리사 밖에 없겠지? 근데 이거 주말 지나고 작성한 거라 이미 시험 쳤음

• github flow & git flow
• 깃허브 인텔리제이 생성 흐름에 대해
• 과제 6단계까지!!!