I think the only correct long-term solution is to implement chunked upload.
This is also a dealbreaker for radio stations which I support that are intending to use Castopod. In many shared hosting environments you're not allowed to increase maximum upload size, such a large max POST size can lead to DoS and it's unlikely that you will be able tu upload such large file without issues unless you have a solid broadband connection, which is hard to get in some parts of the world.
Given that I suggest to mark this as a duplicate of #330.
Currently the upload of an MP3 file happens as a single request.
It leads to numerous problems:
The upload should be handled by chunked upload mechanism, such as tus, resumable.js or similar.
I can consider sponsoring such feature.
We host approximately 50 podcasts on one instance.
Trying to confirm another account while being signed in results in crash.
Human-friendly warning that you need to sign out prior to confirmation or automatic account switch to account B.
Error shows up.
CodeIgniter\Shield\Exceptions\LogicException
The user has User Info in Session, so already logged in or in pending login state. If a logged in user logs in again with other account, the session data of the previous user will be used as the new user. Fix your code to prevent users from logging in without logging out or delete the session data. user_id: 1
at /home/app/vendor/codeigniter4/shield/src/Authentication/Authenticators/Session.php:609
But I won't fight for the naming convention, it's up to you :) What matters here is the functionality.
When it comes to naming - OK.
Adding default limit - OK.
When it comes to splitting search from listing - the use case is that you often want to do both at the same time.
Use cases are simple, imagine the following mobile app having following screens:
I don't really see a reason o create separate /episodes/search
action, as it can be all handled by optional query parameters passed to /episodes
.
The use case for having /episodes
endpoint for listing episodes is similar to fetching RSS feed but from mobile app developer standpoint it's easier to have uniform JSON interface to Castopod instead of creating a separate parser for a RSS format. And that makes things more uniform.
If you agree to keep just /episodes
without /search
suffix, if you want we can add similar query parameters to existing /podcasts
API.
I need to fetch contents from Castopod to other clients, e.g. custom mobile app.
The REST API added in #210 is nice, but it is relatively simple. Currently displaying e.g. list of the most recent episodes (across all podcasts) requires iterating over multiple endpoints.
There should be an endpoint that allows to query episodes, similarly to how we can now query podcasts.
The added endpoints would be
GET /api/rest/v1/episodes
GET /api/rest/v1/episode/{id}
The first endpoint will accept additional optional query parameters, allowing to narrow the search:
order
- string (newest|search) - search method
newest
sort from the newest to the oldest,search
and there's a search parameter given - sort by search match rating starting from the best match,newest
.count
- integer > 0 - amount of records to return
start
- integer >= 0, index of the first record returned
podcastIds
- comma-separated integers - identifiers of podcasts that should be queried
search
- string - search phrase
In case of search it should do a full text search using any mechanism directly available in MySQL/MariaDB on fields
As in case of #210 I'm ready to sponsor such development.
Please let me know if the design of the API is OK and whether we can proceed.
@yassine That's great news
I wonder if one thing should not be fixed to be more consistent with rest of the code base. Currently, the feature flag in the .env is REST_API_ENABLED
while rest of the env vars seems to be rather using convention of database.default.hostname
(however it's hard to tell whether this is a camel case or whatever else due to entries such as database.default.DBPrefix
).
Anyway, shouldn't it be rather something like api.rest.enabled
?
I'd appreciate if you can mention RadioKit Foundation (https://www.radiokit.org) as a sponsor as well. The website is a bit oldschool but will be updated soon and I'd love to mention there we've sponsored Castopod development.
Hi, I noticed the fediverse API but lack of ability to query all podcasts is a showstopper for me.
Itās obviously your decision but I donāt think fediverse API and REST API serve the same purpose and even if you develop fediverse API further I donāt think REST API should be deprecated. Their lifecycle, how they evolve and use cases might vary. A simple example is pagination which should be done differently for programmatic integration than with fediverse (should rather have a cursor or other way to reliably fetch all collection in chunks using multiple requests than having a āpageā parameter). Another example is being able to pass certain query parameters eg for filtering or sorting which are important for integrating with other systems which might be out of scope for fediverse integration.
Anyway for now we will focus of REST :)
Hi, I think the idea to use OpenAPI is fine as it allows us to create API incrementally without breaking compatibility.
I won't be implementing this personally, and the developers will join the thread soon. Once they're here I'd be glad if you can give them access as well and discuss the implementation details with them directly.
My aim is to set up objectives, and they are for the very first version of the API:
GET /api/rest/1.0/podcasts
GET /api/rest/1.0/podcasts/ID
It is important to me that in both cases it returns the RSS feed URL so I can follow it to fetch the episodes.
This is a minimum set of features for me to implement the mobile app and blocker at the moment.
My proposal is that we use such a minimum API as a testbed if that goes well we can discuss adding more entities in a similar manner.
In case of naming I suggest using REST rather than API as it might happen that you will have GraphQL API as well in the future and API will become confusing.
Please let me know what do you think about this, we would like to start coding on Monday.
I need to fetch contents from Castopod to other clients, e.g. custom mobile app.
The most importantly I need to be able fetch list of all feeds stored in Castopod along with their RSS URLs.
I would like Castopod to provide a simple REST API. The authentication might be simple, e.g. predefined basic auth with credentials stored in the env vars/config file.
There might be a GraphQL API but I think it's an overkill for such scenario.
There might be a more sophisticated authentication scheme but it is not always necessary and it's better to develop things incrementally.
I am ready to sponsor & develop a first version of a read-only REST API as I need it ASAP and I can contribute back to Castopod. If you are interested, I would like to receive some guidance on how should it be implemented to match Castopod coding standards.