[BE] Implement Blog Content Management APIs

[davorminchorov]

Business Requirements

As an administrator or content manager, I want to be able to manage the blog posts on the website.

Acceptance Criteria

• [x] There should be a content endpoint which will list blog posts of the website and it will retrieve the following fields:
• ID
• Title
• Slug
• Excerpt
• Author name
• Author profile image
• Publish Date
• Tags
• Creation date
• [x] The blog posts listing endpoint should be sortable by ID, title, publish date and creation date
• [x] The blog posts listing endpoint should be searchable by title, tag and author name
• [x] Content managers shouldn't be able to invite other content managers or administrators
• [x] There should be content endpoints which will create and edit the following blog post details:
• Title
• Excerpt
• Slug
• Content
• Author name
• Author profile image
• Publish Date
• Tags
• [x] There should be an endpoint which will soft delete a blog post from the website
• [x] There should be an endpoint which will publish or unpublish a blog post from the website
• [x] There should be a content endpoint which will view details of a specific blog post with the following fields:
• Title
• Excerpt
• Slug
• Content
• Author name
• Author profile image
• Publish Date
• Tags
• [x] The endpoints should require the administrators and content managers to be authenticated.
• [x] There should be validation for the create and edit blog post endpoints
• [x] There should be endpoints to create, update and soft delete blog post tags
• [x] There should be API documentation generated by Scribe so that the frontend team can integrate it easily.

Related issue:

https://github.com/learnhubmk/api/issues/115

[nikoladomazetovikj]

@davorminchorov There should be an endpoint which will publish or unpublish a blog post from the website

I think there is no need for a separate endpoint, this also can be done by update API as it will be a PATCH method, we will just change the status column

[davorminchorov]

@nikoladomazetovikj I added that line because it will be easier to separate the use case, otherwise you will have to do a bunch of checks in the normal update endpoint in order to know what's happening.

Another downside is that you will have to either send all of the data every time you change a single column or other magical stuff to handle situations where the other columns are not affected in that single use case.

If it's easier for you to reuse the update endpoint, go for it, there's no problem with that approach either. It's up to you to decide.