[Spring Boot 게시판 ②] CRUD API , Postman 테스트(4/4)

시리즈 포스팅!! 

SprintBoot로 게시판 만들기 ②📝(API명세서, ERD작성) - 1

SprintBoot로 게시판 만들기 ②📝(CRUD 구현_설정부) - 2

SprintBoot로 게시판 만들기 ②📝(CRUD 구현_개발) - 3

SprintBoot로 게시판 만들기 ②📝(CRUD 구현_테스트) - 4

 

 

 

 

3-9. `postman`으로 API 테스트 

이 테스트를 하면서 예외처리와 응답 포맷을 추가로 구현했음..

넘 안이뿌게 나오잖아!! 난 진짜 못생긴게 너무싫다.. 코드도.. 생김새도 어쩌고 모든게.. 엄청난 외지주임ㅋ

 

 

1.게시물 조회

• Method: GET
• URL: http://localhost:8082/api/board/
• Headers: 생략 가능

 

 

2. 게시물 상세조회

• Method: GET
• URL: http://localhost:8082/api/board/게시글번호
• Headers: 생략 가능

성공시

실패시 - 게시글번호 없을경우 404 못찾겠고요

 

 

3. 게시물 작성

• Method: POST
• URL: http://localhost:8082/api/board/
• Headers:
  • Content-Type: application/json
• Body (raw - JSON):

{
  "title": "게시글 제목",
  "writer": "user02",
  "boardPwd": "1234",
  "content": "게시글 내용"
}

 

게시글 작성 성공

실패시 ~ 바로 이런것을 하고싶었다!(아이디가 없는경우 ㅋ) 서버오류 500에러 너탓이고요

실패시 - 필수값 입력안함 비번같은거!!! 클라이언트 오류 400~ 내탓입니다~

 

4. 게시물 수정

• Method: PUT
• URL: http://localhost:8082/api/board/1
• Headers:
  • Content-Type: application/json
• Body (raw - JSON):

{
  "title": "수정된 제목",
  "writer": "user02",
  "boardPwd": "1234",
  "content": "수정된 내용입니다."
}

게시글 수정 성공

게시글이 존재하지않을경우 404 못찾고요

게시글 비밀번호 틀렸을 경우 400 잘못줬어용

 

5. 게시물 삭제

• Method: DELETE
• URL: http://localhost:8082/api/board/1?password=1234
• Headers: 생략 가능

석제성공

삭제실패~!

 

4. 질문고민

4-1. 수정, 삭제 API의 request를 어떤 방식으로 사용하셨나요? (param, query, body)

• 수정(PUT)
  • 경로 파라미터(`@PathVariable`) (param)로 게시글 ID를 받고
  • 요청 본문(`@RequestBody`) (body) 으로 수정할 내용을 DTO로 전달했다.
  • `@Path Variable` + `@Request Body`

PUT /api/board/{id} 
Body: { "title": "수정된 제목", "content": "수정된 내용" }

 

•  삭제(DELETE)
  • `@PathVariable` (param) 로 ID를 전달받고
  • `@RequestParam`(query)로 게시물비밀번호를 받았다. 
  • Body는 따로 사용하지않았음 (왜 그랬을까..? 비밀번호 민감정본데..? 나 회사에서 민감정보 교육도받고 미친예민한데..?ㅋㅋ)
  • `@Path Variable` + `@Query Parameter`

DELETE /api/board/{id}?password=1234

 

용어	설명 예시	사용 시점
Path Variable	/api/board/5 → 5가 자원 ID일 때	특정 리소스를 식별할 때
Query Param	/api/board/5?password=1234 → password 값	필터링, 조건 추가, 인증 등
Request Body	{ "title": "변경", "content": "내용" } 등	복잡한 데이터(객체 등)를 전송할 때

 

 

4-2. 어떤 상황에 어떤 방식의 request를 써야하나요?

 

구분	사용 시점	용도 / 의미	예시 URL / Header	설명
Path Variable (param)	조회/수정/삭제 시 식별자 필요할 때	리소스 고유 식별자 전달	/api/board/5	게시글 번호 5번을 조회/수정/삭제
Query Parameter	필터, 검색, 페이징 등	옵션 정보 전달	/api/board/search?keyword=Java&page=2	검색어와 페이지 정보 전달
Request Body	POST/PUT 시 본문 데이터 전송	실제 데이터 전달	Body에 JSON 형태로 전송	게시글 내용 전체 전송 (제목, 내용 등)
Header	인증, 포맷 정보 등 메타데이터	인증, 포맷, 요청 속성	Authorization: Bearer 토큰값Content-Type: application/json	인증된 사용자 요청 / JSON 형태 전송 명시

 

REST는 리소스 식별은 경로, 데이터 전달은 body, 선택 조건은 query로 구분해야 가독성과 일관성이 높다고한다.

 

4-3. RESTful한 API를 설계했나요? 어떤 부분이 그런가요? 어떤 부분이 그렇지 않나요?

RESTful한 API란?

REST는 "REpresentational State Transfer"의 약자로, 다음의 원칙들을 따르면 RESTful하다고 평가한다고함

자원 중심	URL은 명사로, 리소스를 표현 (/board, /user)
HTTP 메서드 활용	GET/POST/PUT/DELETE 등 의미에 맞는 메서드 사용
무상태성 (Stateless)	서버는 요청마다 클라이언트 상태를 기억하지 않음
계층 구조 / 일관성 있는 URI	계층적이고 직관적인 URL 구성
표준 상태코드 사용	200, 201, 400, 404, 500 등 상황에 맞는 응답 코드 제공

 

RESTful 설계 준수한 부분

항목	적용	설명
자원 중심 URI	/api/board/{id}	게시판이라는 자원을 명확히 표현함
HTTP 메서드	GET, POST, PUT, DELETE	기능에 따라 메서드를 적절히 사용함
계층 구조	/api/board, /api/board/{id}	리소스 경로 구조가 깔끔함
상태코드	200, 201, 400, 404, 500 등	상황에 따라 응답 코드를 나눴음
공통 응답 포맷	ApiResponse<T>	일관된 응답 구조로 설계됨

 

아쉬운 부분 또는 개선 여지

항목	예시	개선 방안
비밀번호(민감 정보) query param 사용	/api/board/7?password=1234	RequestBody로 보내는 것이 보안상 더 적절
상태 없는 통신 (Stateless) 기반 설계	인증방식을 세션대신 JWT 토큰을 사용	아직안해서 추후 구현예정!

 

4-4. 적절한 관심사 분리를 적용하였나요? (Controller, Repository, Service)

제법 잘 분리했지요~?

계층	폴더	역할(관심사)
Controller	`controller`	- 클라이언트 요청을 받아서 적절한 서비스 호출- HTTP 상태코드 및 응답 포맷 정의 - 주로 `@RestController`, `@RequestMapping`, `@Get/PostMapping` 등 사용
Service	`service`	- 실제 비즈니스 로직 담당- 트랜잭션 처리, 유효성 검사 등 구현 - Controller → Service 호출 구조로 이어짐
Repository	`repository`	- DB에 접근해서 CRUD 수행 (JPA 기반) - `JpaRepository`를 상속해서 기본 메서드 제공 (save, findById 등)
Domain (Entity)	`domain`	- DB 테이블과 1:1 매핑되는 클래스 - JPA Entity 역할 (`@Entity`, `@Id` 등 포함)
DTO	`dto`	- Controller ↔ Service 간 데이터 전달 객체 - Entity를 외부에 노출하지 않도록 보호하는 역할
Exception	`exception`	- 커스텀 예외 클래스 (`BoardNotFoundException` 등) - 전역 예외 처리기능 구현 (`@RestControllerAdvice`)
Common	`common`	- 응답 공통 포맷 클래스 (`ApiResponse<T>`) - 전체 API 응답 형식을 통일
Validator	`validator`	- `@Valid`유효성 검사 기능
Templates / Static	`templates`, `static`	- Thymeleaf를 이용한 View 렌더링 (MVC 화면)- 정적 리소스 (CSS, JS 등) -> 첨에 실수로 구현했었는데 안지웠음

 

4-5. API 명세서 작성 가이드라인을 검색하여 직접 작성한 API 명세서와 비교해보세요!

넹~ ~~나는 API 명세서가 개발전이랑 개발 후가 좀 다른편인데 

개발전엔 사실 대강..갈겼고 메서드라던가 기타등등 ~ 

개발하면서 오..재밋네 하면서 계속계속 수정하면서 개발했기때문에 비교적 RESTful한 API가 되어서 그에따른 명세서가 잘나온듯..

순서가 뒤죽박죽 우당탕탕 이었음 ..ㅋ 

 

내가 나중에 보려고 작성한 글이기때문에 꽤나 자세하게 적었다.. 

공수가 제법 들어감.. 

 

이제 로그인 회원가입 분을 위해서 힘내보작오.. 토큰안써바서 긴장댐  -끗.-