https://documenter.getpostman.com/view/15629392/2s8Z6sbb72
- 수정, 삭제 API의 request를 어떤 방식으로 사용하셨나요? (param, query, body)
- 수정시 새로운 게시글을 작성하는 양식과 동일한 이름, 비밀번호, 작성자, 내용을 body로 받아 비밀번호를 확인 후 수정완료가 되게 하였습니다. 다만 query 나 param 형식과 달리 URL에 입력한 정보들이 드러나지는 않습니다만 클라이언트에서 해당 요청의 body를 보면 입력한 정보들이 고스란히 노출되는 것을 확인했습니다. https 를 사용하거나 클라이언트쪽에서 요청을 하기전에 데이터를 가공시키는 작업이 필요할 것 같습니다.
- 삭제시에는 게시물 조회를 위한 식벽자를 param으로 입력받고 비밀번호는 body로 받았습니다. 위와 동일한 문제가 있습니다.
- 어떤 상황에 어떤 방식의 request를 써야하나요?
- resource 에 접근을 하는데 기본값 외의 특별한 기준으로 해당 resource를 얻고 싶다면 RUI에 드러나게 GET과 같은 요청을 사용하면 될 것 같습니다. 이 외의 보안관련 사항 인증, 인가 등등은 post와 다른 보안방법들을 같이 이용하면 될 것 같습니다.
- RESTful한 API를 설계했나요? 어떤 부분이 그런가요? 어떤 부분이 그렇지 않나요?
-
- 접근하고자 하는 resuouce 는 URI 로 포현하고 행위는 HTTP Method를 통해 표현하였습니다.
- 적절한 관심사 분리를 적용하였나요? (Controller, Repository, Service)
- 나름 고민하고 또 고민하고 있습니다... 확장이 필요해 보이는 부분이 있는데 클래스가 하나밖에 없으니 오히려 추가하는 것이 더 번거롭고 불필요한 작업이라고 생각해서 분리하지는 않았습니다.
- API 명세서 작성 가이드라인을 검색하여 직접 작성한 API 명세서와 비교해보세요!
- 네
- 처음 설계한 API 명세서에 변경사항이 있었나요?
변경 되었다면 어떤 점 때문 일까요? 첫 설계의 중요성에 대해 작성해 주세요!
- 사용자 로그인이 추가되면서 데이터의 추가,변경 및 삭제와 관련된 인증방식에 변경이 생기면서 request-body에서 필요로 하는 값의 변경이 있었습니다.
- 작성하면서 많은 의문이 생겼습니다. 개인적으로 많이 번거로운 작업이라고 생각을 했습니다. 판매용 프로그램이라면 api를 문서화해야하는 것에 동의를 합니다만 사내에서 사용되고 코드내부를 볼 수 있는 환경이라면 작성을 해야하나? 라는 생각이 떠나질 않습니다. 문서화를 한다면 지속적인 동기화작업을 해줘야 하는데 이게 잘 이루어 질까? 라는 의문도 생기고 코드 자체가 문서가 아닌가? 하는 생각도 가지고 있습니다.
- ERD를 먼저 설계한 후 Entity를 개발했을 때 어떤 점이 도움이 되셨나요?
- 클래스의 필드와 관계설정을 할때 시각적으로 도움을 받을 수 있는 자료가 있어서 작성하기 수월했습니다.
- JWT를 사용하여 인증/인가를 구현 했을 때의 장점은 무엇일까요?
- stateless서버를 만들 수 있기에 서버 확장성이 좋습니다.
- 서버가 가용하는 resource를 최소한으로 유지할 수 있습니다.
- 반대로 JWT를 사용한 인증/인가의 한계점은 무엇일까요?
- 매요청시 requset에 포함시켜아한다는 단점이 있습니다.
- 댓글이 달려있는 게시글을 삭제하려고 할 때 무슨 문제가 발생할까요? JPA가 아닌 Database 테이블 관점에서 해결방법이 무엇일까요?
- Cascading deletes, Stored procedures, Database triggers
- 5번과 같은 문제가 발생했을 때 JPA에서는 어떻게 해결할 수 있을까요?
- key를 소유하고 있지 않다면 cascade or orphanRemoval 속성을 사용합니다.
- IoC / DI 에 대해 간략하게 설명해 주세요!
- 코드에서는 추상적인 것에 의존하게하고 IoC를 통해 객체의 생성 및 관계를 맺는 작업을 위임하고 Runtime시에 실제객체를 DI한다