mirror of
https://github.com/jellyfin/jellyfin.git
synced 2026-07-16 05:43:54 +03:00
[PR #8285] Introduce Clearer Authentication Requests #11672
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Original Pull Request: https://github.com/jellyfin/jellyfin/pull/8285
State: closed
Merged: No
🚧 in progress of deprecating old APIs and rewriting summary 🚧
This PR simplifies the authentication requests, by:
Pw -> PasswordWhy
I recently refactored the Swift Jellyfin SDK and created a client object for some helpful usage. Part of this was wrapping the authentication request and through that I found this area to be somewhat messy, so I thought as part of my first contribution it would be easy since it was small.
Justifications
Jellyfin-web does not use this endpoint and I looked through a few other clients and they don't as well. Removal of this consolidates the authentication requests. Additionally, if a client has a method of obtaining user IDs they should have a method of obtaining usernames as well. I also found this specific route to be odd.
This parameter was marked obsolete early 2021. It's been over a year now and I strongly value a clearer name than holding onto obsolete implementations. I don't remove the obsolete property entirely from many other places, like
AuthenticationRequest, in this PR.It's odd to use a small phrase in an API call. By a quick scan a lot of the server's other routes follow good noun/command conventions and these ones just stood out.
This is just me not liking the
dtoconvention. The contextual usage of these objects are for requests and also matches other object names likeAuthenticationRequest.This would be a breaking change for all authentication requests and is just a very small transition.
Thoughts
From working with Jellyfin for over a year now and refactoring the Swift SDK I've started to have some thoughts about how we can make a cleaner API. There are ~408 total API calls in this project and I will never attempt to look at all of them. I'm playing a sort of whac-a-mole with the calls that I use directly/most often.
I'm not a Senior REST API developer so this is also a learning opportunity for me and I welcome all discussions either here or in the developer channels about this work here and in the future. This work can be part of minor 10.X updates or as a part of the beginning of a major 11.0 update.