API 패키지 , MVC 패키지 분리
-
API와 MVC의 공통 처리는 완전히 다름
-
API는 정해진 API 스펙을 응답해야하지만, MVC는 뷰 템플릿 경로로 응답을 하게 됨
-
예외 처리 또한 정해진 예외에 대한 API 스펙을 상대방에게 뿌려줘야 하지만, MVC는 에러 페이지를 리턴하게 됨
-
애초에 MVC 패턴의 컨트롤러는
@Controller을 쓰고 API통신을 위한 컨트롤러는 일반적으로@ResponseBody를 응답 시에 어노테이션을 붙여야하므로@Controller과@ResponseBody가 합쳐진@RestController을 씀 -
예외 처리 또한 MVC는
@ControllerAdvice, REST API는@RestContrllerAdvice에서 처리해줌
CRUD와 RESTful API
HTTP 메서드의 특징
-
자원에 대한 행위를 나타내는 4가지 Method는 CRUD에 각각 대응됨
-
POST는 Create(생성, 저장) , PUT은 Update에 매칭 , GET은 Read에 매칭 , DELETE는 Delete에 매칭
-
Content-Type: application/x-www-form-urlencoded로 요청되는 HTML Form 방식에선 수정 또한 POST 했지만, Html Form 방식에선 GET POST만 지원하므로 그렇게 된 것 , 그래서 조회(GET) 빼곤 전부 POST였던 것!
6/image.png)
왜 수정 시에 POST가 아닌 PUT 일까?
-
바로 멱등성 때문임
-
POST는 멱등성을 보장하지 않음 , 여러 번의 같은 POST 요청을 보내면 데이터가 수정이 아닌 새로운 등록이 되고 결제 또한 중복된 결제가 됨
-
즉 그에 따라 없으면 생성 있으면 대체하는 PUT의 특성상 멱등하므로 100번이든 10000번이든 같은 요청 시 언제나 항상 같은 결과를 내놓게 됨
★ API 요청/응답 시 API 스펙과 일치하는 DTO 지정
-
컨트롤러에서 API 응답 시엔 “DTO”를 통해 JSON 형태로 매핑이 돼야됨
-
예를 들어 응답할 때
List<Member>와 같이 실제 엔티티를 응답하게 되면 Member과 연관관계에 있는 Order , Item 따위들에 대한 데이터 또한 같이 나가게 됨 -
@JsonIgnore이라는 어노테이션을 연관관계 필드에 지정할 순 있지만, 결국 해당 어노테이션 건다는 자체가 프레젠테이션 계층 기술이 고유의 도메인 엔티티에 침범하는 꼴이 되므로 도메인과 화면을 담당하는 web 계층 과의 경계가 무너짐 -
그리고 또한 엔티티의 필드가 name = > username으로 바뀌면 API 스펙 자체가 name에서 username으로 바뀜
➤ API 스펙은 상대 클라이언트와 맞춘 협약인데 이게 무단으로 바뀌면 큰 혼란을 야기시킴
-
즉 그에따라 무조건 조회든 수정이든 등록이든 응답용 DTO를 만들어서 운영해야됨!
API 응답 시 컬렉션 지정 X
- 컬렉션을 리턴하게 되면 API형식이 대괄호로 묶여버리기 때문에 추후 API를 확장해야할 일이 생길 경우 확장이 불가능해짐
- 즉 필드 안에 리스트가 들어가는 구조로 돼야됨
올바른 JSON 형식
{
“data”:”[
{“name”:”kevin”} , {“name”:”anna”} , {“name”:”marthin”}
]”
}위와 같이 중괄호가 맨 처음에 나와야 돼야 데이터를 추가할 수 있음
{
"count":100
“data”:”[
{“name”:”kevin”} , {“name”:”anna”} , {“name”:”marthin”}
]”
}총 개수인 count 값을 추가할 수 있었음
잘못된 JSON 형식
[
{“name”:”kevin”},
{“name” : “anna”},
{“name”:”marthin”}
]위와 같이 중괄호가 아닌 대괄호로 묶이게 되면 더 이상의 확장이 불가능
