게시물 전체 목록 api

Feed에 나타나는 게시물 목록 API

query	속성	default(미입력 시 값)	설명
hashtag	string	본인계정	맛집, 성수동 등 1건의 해시태그 이며, 정확히 일치하는 값(Exact)만 검색합니다.
type	string		게시물의 type 필드 값 별로 조회가 됩니다. 미입력 시 모든 type 이 조회됩니다.
order_by	string	created_at	정렬순서이며, created_at,updated_at,like_count,share_count,view_count 가 사용 가능합니다. 오름차순 , 내림차순 모두 가능하게 구현
search_by	string	title,content	검색 기준이며, title , content, title,content 이 사용 가능합니다. 각각 제목, 내용, 제목 + 내용 에 해당합니다.
search	string		search_by 에서 검색할 키워드 이며 유저가 입력합니다. 해당 문자가 포함된 게시물을 검색합니다.
page_count	number	10	페이지당 게시물 갯수를 지정합니다.
page	number	0	조회하려는 페이지를 지정합니다.

게시물 목록 API에선 content 는 최대 20자 까지만 포함됩니다.
- 기타 필드 추가하셨을 경우, 목록 구성에 필요하지 않은 필드는 제외 합니다.

페이지네이션 적용 page_count = 10

게시물을 구현할때 각 CBV의 장단점 입니다. 구현 하고 계시곘지만 참고하시고 구현해주시면 감사하곘습니다.

DJango에서의 vIew는 APIView > Mixins > GenericCBV > ViewSet 순으로 되어 있으며 왼쪽 view를 상속받아 구현됩니다. 또한 오른쪽으로 가면 갈 수록 view를 간단하게 구현할 수 있다는 특징이 있습니다.

APIView 제일 기본 적인 VIew이며 딱 추가하고자하는 기능만 만들수 있다는 장점이 있지만 코드가 길어지고 처음부터 만들어야한다는 단점이 있습니다.
Mixins 반복적인 기능을 하나의 Mixin 클래스로 제공한다면 반복적인 일을 줄여주고 가독성, 생산성을 높여줄 수 있습니다. 단점은 Mixin 클래스에 존재하는 메소드나 속성을 상속받는 클래스에서 사용할 경우 믹스인 클래스의 메소드가 오버라이딩되어 의도하지 않게 작동할 수 있으니 주의해야 합니다.
GenericCBV 왠만한 기능들이 구현 되어 있으며 api 기능들도 분리가 되어 있어 각 api에 맞게 구현할 수 있도록 구현되어 있습니다. 여러 apiView와 Mixin의 기능을 합텨놓아 반복성을 줄일 수 있다는 장점이 있습니다. 또한 커스터마이징에 용이하기 때문에 필요에 따라 APIView 등을 상속받아 사용할 수 있습니다.
ViewSet 왠만하면 RESTAPI CRUD기능이 모든 기능이 다 구현되어 있어 변수 설정만 해주면 api를 한번에 구현 할 수 있다는 장점이 있지만 코드를 뜯어봐야 이해 할수 있고 api 기능들 구현에 있어 역할이 나눠져 있는경우 코드를 합하는데 있어 충돌이 일어날 가능성이 많습니다.

이를 비교해 봤을때 현재 저는 기능을 나누어 구현해야하고 왠만한 기능이 구현되어 있는 GenericView가 합당하다고 생각했습니다, 긴 글 읽어 주셔서 감사합니다.

I-deul-of-zoo / wanted-feed-service