Add REST API pt. 3 - Add Magazine User/Moderator/Owner APIs #950
Labels
No Label
a11y
ActivityPub
admin
API
backend
bug
community
conflicting
contribution welcome
deployment
documentation
duplicate
enhancement
frontend
good first issue
help wanted
high priority
instance config
low priority
mobile
moderation
more infomation needed
needs feedback
pr pending
project setup
question
search
security
translation
translations update needed
UI/UX
upstream
No Milestone
No project
No Assignees
4 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: Kbin/kbin-core#950
Loading…
Reference in New Issue
There is no content yet.
Delete Branch "rideranton/kbin-core:feature/api-magazine"
Deleting a branch is permanent. Although the deleted branch may exist for a short time before cleaning up, in most cases it CANNOT be undone. Continue?
This PR is one of a series of PRs adding the API in chunks to help aid the review process!
The previous PR is here
Changes in this PR:
97dcc8cc2e
to5efbbc7560
5efbbc7560
todb94101975
WIP: Add REST API pt. 4 - Add Magazine User/Moderator/Owner APIsto WIP: Add REST API pt. 3 - Add Magazine User/Moderator/Owner APIs86c44f6abf
to5abdc28ad5
5abdc28ad5
tod9d585134c
ca42ec7a34
to13fb2bf526
7b6af15804
tob5fbc9149e
b5fbc9149e
to884a9e22a7
5620bb5c68
tob462927288
b462927288
to70ba9bcfd3
70ba9bcfd3
tod370713ea5
WIP: Add REST API pt. 3 - Add Magazine User/Moderator/Owner APIsto Add REST API pt. 3 - Add Magazine User/Moderator/Owner APIsSweet, I'll be testing today. Thanks.
97fdf0c837
tobc01c713e1
@ -36,3 +36,3 @@
KBIN_CAPTCHA_ENABLED=false
# Only let admins generated oauth clients
# Only let admins generate oauth clients
KBIN_ADMIN_ONLY_OAUTH_CLIENTS=false
this env var shouldn't be between KBIN_CAPTCHA_ENABLED and other CAPTCHA env vars
@rideranton This seems to be fixed on develop. Try to rebase?
@ -0,0 +2,4 @@
api_magazine_entries_retrieve:
controller: App\Controller\Api\Entry\MagazineEntriesRetrieveApi
defaults: { sort: hot, time: ∞ }
path: /api/magazine/{magazine_id}/entries/{sort}/{time}
I think query params should be used for all filters and sorting, for consistency in all endpoints
That endpoint is using the convention set by the entry front endpoints
Also it probably shouldn't have been included in this PR since the Entry API controllers aren't included here
Exactly, those are front routing endpoints, while it makes sense to have "pretty urls" like those on the website, I believe that in API meant for other developers, mixing path variables and query parameters, in this endpoint or any other, is confusing
Sure, that makes sense - I'll remove the paths that aren't used in this PR and when they are added in a later PR I'll change the path variables to query parameters
what is your conclusion after 2 weeks?
7d5b5f47c3
to6b8106f60f
83b2a31aff
tofb5cac0049
fb5cac0049
to597434d841
597434d841
to2a515e125c
2a515e125c
toe5b204bc76
e5b204bc76
toebad492c4d
Regression impact! #1094, #1097.. and properly more issues..