В теории можно выдавать ошибку "Object already exist" для полного феншуя при повторном лайке лайкнутого, но на практике это будет бред в стиле Шелдона)

если мы идем по пути создания лайка как сущности, тогда логичнее создать новый ендпоинт /api/likes и отправлять на него POST с post_id в теле

я понимаю, но с теми ендпоинтами что у тебя, получается что с внешней стороны (со стороны апи) ты правишь сущность post, меняя ее св-во like, внутри, в коде ты уже можешь сохранять этот лайк как тебе угодно

в общем я бы делал именно PUT /api/posts/ID/like

Звучит логично

Согласен. Тогда в теле PUT можно отправлять лайк, дизлайк, сердечки, ухты и прочие рюшечки как с фейсбука

Привет, можно тупой вопрос задать? Я могу с помощью монолитного (не дрф) джанго захостить вью и отдавать его как - нибудь статикой ?

Если да
Скиньте пожалуйста линк на почитать

кстати интересно =)

Просто отдавать статику? https://docs.djangoproject.com/en/2.2/howto/static-files/

Для просто статики джанга не нужна, ребят

не, вопрос наверное скорее про то  как отрендерить vue как ssr и отдать внутри куска шаблона джанги? @cmp_to_key так?

можно почитать советы от Google'а на эту тему: https://cloud.google.com/apis/design/custom_methods

точно не get. get не должен менять данные

Ребят, нужен совет не так связанный с джанго, как с базами данных.
Есть предметы, они содержат число лекций, пз и лабораторных. Нужно хранить оценки каждого студента группы по всем этим пунктам. Препод может менять количество лаб и добавлять потом всем баллы.
У меня в голове есть два варианта хранения всего этого счастья:
1. хранить число баллов в виде слияния цифр (если студент получил по 2 лекциям 2 балла и по 1 пз 5 баллов, то его баллы будут хранится вот так "225". Число лекций, пз и лаб будет храниться в другой таблице, чтоб препод мог менять их. И в итоге это все на беке просто разделять.
2. Хранить каждую оценку каждого студента по каждому виду работ, но тогда нужно думать, как обеспечить добавление и нумерацию этих оценок преподом
Какой из варинтов вы бы выбрали?

я бы выбрал второй. прозрачность всегда лучше

Просто при втором варианте я не могу понять, как сделать разделение видов баллов (за лк, за пз, или за лабу) так, чтобы ещё и сохранялась их последовательность, чтоб можно было вывести эти баллы в виде таблицы. В первом варианте они бы просто добавлялись в нужное место в слиянии цифр

Так

Каждый раз думаю, вот сейчас сделаю сайтег на django cms, устанавливаю смотрю... да красиво, удаляю проект и делаю на фрейворке, мляха-муха, второй год уже так:)

как вариант, постгресовский jsonfield (=хранение питон-словаря в базе данных). ключи словаря - айдишники предметов/лаб