021 - 본수업 15일차 / 스프링 입문 주차 : 개인 과제 질문편

 

 

 

주어진 질문

1. 수정, 삭제 API의 request를 어떤 방식으로 사용하셨나요? (param, query, body)
2. 어떤 상황에 어떤 방식의 request를 써야하나요?
3. RESTful한 API를 설계했나요? 어떤 부분이 그런가요? 어떤 부분이 그렇지 않나요?
4. 적절한 관심사 분리를 적용하였나요? (Controller, Repository, Service)
5. 작성한 코드에서 빈(Bean)을 모두 찾아보세요!
6. API 명세서 작성 가이드라인을 검색하여 직접 작성한 API 명세서와 비교해보세요!

 

 

---

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

body방식을 선택했다. 비록 프론트 부분이 없으나 게시판 기능을 하는 거였고, 건네 받을 데이터 중에는 url에 드러나지 말아야할 패스워드와 url로 들어가면 너무 길어지는 글 내용이 포함되어 있었다. 따라서 Request body에 데이터를 포함시켜 전달하는 body방식을 사용해 JSON으로 제출하는 것을 선택했다.

 

 

+

REST API의 parameter 4가지 타입

- header : Requet Header에 포함된 파라미터. 보통 인증 혹은 권한 부여에 관련되어 있다.

- path : 엔드포인트에서 쿼리문 이전의 파라미터. (ex.https://news.naver.com/main/list.naver?mode=LSD&mid=sec)

- query string : 쿼리문 내의 파라미터. 엔드포인트가 끝난 뒤 물음표 뒤에 온다. (ex.https://news.naver.com/main/list.naver?mode=LSD&mid=sec)

- request body : 리퀘스트 바디에 포함된 파라미터. 보통 JSON 형식으로 제출된다.

 

재미있는 REST API 파라미터의 종류와 개요

이진님이 알려주신 파라미터 설명 링크

@RequestParam, @PathVariable, @RequestBody

---

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

상황별 Request) 

• @RequestParam

URI의 QueryString으로 넘어오는 파라미터를 받는 Request 방식이다. 보통 정렬이나 필터링, 페이징을 적용하고자 할 때 사용된다. 

ex) http://localhost:8080/api/memo?name=littlezero

 

@RequestParam("name") String name  식으로 사용되며

RequestBody와 달리 받을 데이터 이름을 설정 해주어야 하며 이에 해당하는 데이터만을 받을 수 있다. 

해당하는 파라미터가 URI에 없으면 에러가 발생한다. 

 

+ URI의 파라미터 이름과 @RequestParam 정의시 변수명이 동일하면 "" 안의 이름은 생략해도 된다고 한다.

ex) @RequestParam("") String name

+ 가끔 어떤 파라미터는 @ReqeustParam을 쓰고 어떤 파라미터는 @RequestParam을 생략해서 요청을 받는다.

@RequestParam을 생략하면 내부적으로  String이나 Long 같은 타입은 @ReuqestParam으로 취급하고 그 이외에 파라미터는 @ModelAttribute로 취급

 

• @PathVariable

URI의 경로의 일부를 파라미터로 받는 Request방식이다. 

REST API 호출시 많이 사용하는 방식으로 구체적으로 리소스를 식별하여 사용하고자 할때 사용한다. 

 

• @RequestBody

HTTP Request의 Body에 담긴 값을 객체로 변환하여 받는 Request방식이다.

일단 URI에 해당 데이터가 노출되지 않아, 숨겨야할 데이터 또는 URI에 다 담을 수 없이 긴 데이터 등을 처리할 때 사용한다. xml이나 json기반의 메시지를 사용하는 경우 유용하다.

 

 

 

상황별 메소드) 

• GET 

자원의 수정 없이 오로지 데이터를 조회할 목적일 때 사용하는 방식이다. CRUD에서는 R. Read 부분에 해당한다. DB로 치면 Select에 해당. 이번 과제에서는 메모글을 모두 조회하는 데에 사용했다.

• POST

자원를 생성하여 추가할 때 사용하는 방식이다. CRUD에서 C. Create 부분에 해당하며, DB로 치면 Insert에 해당. 이번 과제에서 메모글을 새로 작성하여 저장하는 데에 사용했다.

• PUT

자원를 변경할 때에 사용하는 방식이다. CRUD에서 U. Update에 해당하며, DB에서도 Update에 해당한다. 이번 과제에서 메모글을 수정하는데에 사용했다. 

참고로 PUT은 자원을 모두 대체(replace)하는 메소드이다. 요청한 URL 아래에 해당 자원이 존재하지 않으면 POST와 마찬가지로 새로운 자원으로써 저장한다. 만약 요청한 URL 아래에 해당 자원이 존재하면 기존에 존재하던 자원을 새롭게 요청으로 들어간 정보로 자원 전체를 대체한다. 만약 PUT을 사용하여 일부만 변경하고자 하여 자원의 전체 상태를 완전하지 못한 상태로 전송한다면 일부가 null값으로 변경될 수 있다. 

• PATCH

PATCH 역시 데이터를 변경할 때 사용한다. 하지만 PUT과 PATCH는 서로 대체제 관계가 아니며, 다른 정의와 규약을 가지고 있다. PATCH 요청은 자원에 대한 부분적인 수정을 적용하기 위한 메소드이다. 따라서 필요한 정보에 대해서만 요청할 수 있다. 

• DELETE

자원를 삭제할 때 사용하는 방식. CRUD에서 D. Delete에 해당하며, DB에서도 Delete에 해당한다. 이번 과제에서 메모글을 삭제하는 데에 사용했다.

 

+ 멱등성 (idempotent) 

멱등성의 멱(冪)은 거듭제곱이란 뜻이 있으며 등(等)은 같다는 뜻을 가지고 있다. 

거듭해도 같다는 뜻으로 수학에서는 연산을 여러번 적용하더라도 결과가 달라지지 않는 성질을 의미하며, 웹에서는 동일한 요청을 한 번 보내는 것과 여러번 연속으로 보내는 것이 같은 효과를 지니고, 서버의 상태에도 동일하게 남을 때, 해당 HTTP 메소드가 멱등성을 가졌다고 한다.

 

REST API와 GET, POST, PUT, DELETE 통신에 대해

자원을 수정하는 HTTP 메서드 - PUT vs PATCH

 

 

 

---

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

REST라고 하면 HTTP라는 프로토콜을 이용해 웹에서 제공하는 모든 자원을 하나하나 식별할 있는 고유한 주소인 URI를 이용하여 HTTP 메소드를 통해 CRUD 처리하는 방식을 말한다.

그리고 RESTful API란 REST를 REST 답게 원리를 잘 따라 설계한 API를 말한다. 

 

일단 강의를 기준으로 해서 상황에 따른 적절한 CRUD를 사용했다고 생각하므로 RESTful한 설계가 되었다고 생각하지만, 아직 PUT이나 PATCH에 대한 차이를 정확하게 모른채로 사용해서 개인적으로 RESTful한가에 대한 의문이 있다.

 

API명세서 예시를 보면 URL이 동일하게 하고 Id가 필요한 경우만 뒤에 경로를 더 붙여 달리하여 Request의 요청 방식따라 달리 받게 했는 데, 내가 진행한 과제에서는 URL을 아예 다 다르게 써서 오히려 더 비효율적으로 한게 아닌가 생각이 든다.  
매니저님께 여쭤보니 RESTful한 API에는 URL에 동사를 사용하지 않는다고 하셔서 동사를 사용해 url을 다 다르게 만들어 RESTful하지 못했다.

 

---

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

관심사 분리(SoC, Separation Of Concerns)란 객체 지향 프로그래밍(OOP, Object-Oriented Programming)의 5대 설계 원리인 SOLID 중 S에 해당하는  Single Responsiblity Principle (SRP, 단일 책임 원칙) 의 원리에 따르는 것으로 하나의 역할은 하나의 역할 수행에만 집중해야 함을 의미한다.

 

이번 과제에서 Controller와 Repository 그리고 Service를 구축하면서 해당 클래스가 그에 맞는 역할을 가지고 그 역할을 수행하는 데에만 집중할 수 있게 했느냐는 것이 관심사 분리를 제대로 적용한 것이라 볼 수 있다.

 

• Controller는 사용자의 요청이 진입하는 시작점이자 중앙 제어자. 사용자의 요청과 데이터를 받아 적절한 Service 메소드로 연결해주고 Service를 통해 처리가 된 모델을 뷰와 함께 응답으로 보내주는 역할을 한다.
• Service는 Controller를 통해 전달 받은 정보를 가공하는 과정 즉, 비즈니스 로직을 수행하는 역할이다. 이 과정에서 필요하면 Service는 데이터베이스에 접근하는 DAO(Data Access Object)를 이용해 데이터를 받아와 로직을 수행하기도 한다.
• Repository는 Entity에 의해 생성된 DB에 접근하는 메소드 들을 사용하기 위한 인터페이스이다. 사용하고자 하는 CRUD를 어떻게 할 것인가 정의해주는 계층이다.

 

과제에서 Controller는 로직에 관여없이 철저하게 요청에 따른 연결을 해주는 역할 만을 수행했다.

Service는 데이터에 대한 모든 비즈니스 로직에 관련하여 수행하여 가장 큰 비중을 차지했다.

Repository는 Entity에 의해 생성된 DB로부터 어떤 방식으로 필터링하여 가져올 것인가 정의를 진행했기 때문에 전체적으로 적절한 관심사 분리가 이루어졌다고 생각한다. 

 

 

 

Controller, Service, Repository 가 무엇일까?

 

---

작성한 코드에서 빈(Bean)을 모두 찾아보세요! 

스프링에서 빈으로 등록하기 위한 어노테이션으로는  @Configuration + @Bean,  @Component 어노테이션이 있으면 스프링 빈으로 자동 등록되는데 @Component를 포함하는 @Controller, @Service, @Repository 어노테이션들도 역시 빈으로 등록된다. @Configuration 에도 @Component가 포함되어있다.

 

@Service, @Repository 등이 이번 과제에 사용 되었으며 기본 @Controller이 아닌 @RestController를 사용했는데 이것도 기본적으로 @Controller + @ResponseBody를 결합한 것이라 @Component를 포함하므로 이역시 Bean으로 등록된다.

 

+

스프링 Bean이란? ) 

 

스프링의 특징에는 제어의 역전(IoC / Invention Of Control)이 있다.

제어의 역전이란, 간단히 말해서 객체의 생성 및 제어권을 사용자가 아닌 스프링에게 맡기는 것이다. 객체에 IoC가 적용된 경우에는 이러한 객체의 생성과 사용자의 제어권을 스프링에게 넘기게 되며 스프링의 DI(Dependency Injection) Container에 의하여 관리당하는 자바 객체를 사용자는 사용하게 된다. 이 객체를 '빈(bean)'이라 한다.

 

[Spring Boot] 스프링 빈(bean)이란? 스프링 빈 등록하는 방법

 

 

---

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

내가 작성한 API 명세서

기능	Method	URL	Request	Response
모든 게시글 조회	GET	/api/memos	-	배열로, modifiedAt 내림차순 {         "result": null,         "message": null,         "id": 6,         "title": "제목1",         "author": "글쓴이1",         "content": "내용입니다",         "createdAt": "2022-11-30T15:02:36.775326",         "modifiedAt": "2022-11-30T15:02:36.775326"   }
게시글 작성	POST	/api/memoWrite	{     "title" : "제목1",     "author" : "글쓴이1",     "password" : "12345",     "content" : "내용입니다" }	{     "id": 7,     "title": "제목1",     "author": "글쓴이1",     "content": "내용입니다",     "createdAt": "2022-11-30T15:04:52.0866289",     "modifiedAt": "2022-11-30T15:04:52.0866289" }
선택한 게시글 조회	GET	/api/memos/{id}	id = 1	{     "id": 1,     "title": "제목1",     "author": "글쓴이1",     "content": "내용입니다",     "createdAt": "2022-11-30T15:02:32.360081",     "modifiedAt": "2022-11-30T15:02:32.360081" }
선택한 게시글 수정	PUT	/api/memoModify/{id}	id = 1, {     "title" : "제목1",     "author" : "글쓴이1",     "password" : "12345",     "content" : "내용입니다" }	{     "id": 1,     "title": "제목1234",     "author": "글쓴이1234",     "content": "수정해봅시다",     "createdAt": "2022-11-30T15:02:36.775326",     "modifiedAt": "2022-11-30T15:03:25.516594" }
선택한 게시글 삭제	DELETE	/api/memoDelete/{id}	id = 1, {     "password" : "12345" }	{     "result": "Success",     "message": "글을 성공적으로 지웠습니다" }

 

예시와 비교했을 때 고쳐야 할 점) 

유사한 기능은 모아두기

여러 데이터를 Response을 할 때는 단 한개만 보여주지 말고 2-3개 보여주기

URL에 경로로 주어지는 path값의 id는 Request란에 포함 시키지 않고 URL에만 추가하기

 

API 명세서 작성 가이드라인을 검색해서 본 것과 비교했을 때 고쳐야 할 점) 

여러 명세서 중에는 Response로 돌아오는 각 데이터들에 대한 예시만 보여주는 게 아니라 데이터 파라미터에 대한 타입부터 이것의 의미하는 것까지 상세 설명을 적는 케이스도 있었다. 상세하게 적어놓은 것을 보니 이 API를 처음 접한 사람도 이 요청이 무엇을 위한 것이고 어떤 값을 받는지 이해하기 쉽게되어 있었다.

검색해보니 API는 이렇게 작성해! 라는 정해진 답은 없는 거 같았다. 여러 API 명세서를 읽어보면서 API 명세서를 작성하는 좋은 방법에 대해서도 생각해봐야 할 듯 하다. (심지어 API 명세서를 작성하기위한 프로그램도 존재한다.)

 

 

 

* 항해의 API 명세서 예시