Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[1.0] API response format for action fields #5532

Open
Nutomic opened this issue Mar 24, 2025 · 1 comment
Open

[1.0] API response format for action fields #5532

Nutomic opened this issue Mar 24, 2025 · 1 comment

Comments

@Nutomic
Copy link
Member

Nutomic commented Mar 24, 2025

At the moment API responses on main branch look like this (excerpt from /api/v4/community):

{
	"community_view": {
		"community_actions": {
			"community_id": 3,
			"person_id": 2,
			"followed": "2025-03-24T10:15:47.709074Z",
			"follow_state": "Accepted",
			"became_moderator": "2025-03-24T10:15:47.705749Z"
		},
		"instance_actions": null,
		"can_mod": true,
                ...
	},
        ...
}

There are a few problems with this:

  • Timestamps for fields like subscribed, blocked or became_moderator are completely unnecessary. These dont exist in 0.19 and were never requested in any issue. For mod actions the timestamps are stored in the modlog anyway. It is also very unintuitive that clients need to compare with null to find out if a user is moderator or was banned. So these should be changed back to simple booleans. It may even be worth changing the original smoosh-tables-together migration, as writing bools should be much faster than generating timestamps.
  • Field names should be simplified to be as before, ie banned instead of received_ban, is_moderator instead of became_moderator etc.
  • Structs like instance_actions are nullable, which makes it impossible to explore the API by browsing the site and observing requests in browser dev tools. This means that client devs need to check the documentation every time, which makes development unnecessarily complicated. We should change it so that if no db row instance_actions exists, a default value is returned with null/false values.
  • Fields community_id, person_id etc are unnecessary for clients and can be marked serde(skip), or even completely removed from the Rust structs.

All these changes will make it easier for clients to adopt the new API, and make the migration to 1.0 smoother.

@dessalines
Copy link
Member

dessalines commented Mar 24, 2025

The timestamps are nice to have and don't hurt anything. I imagine some apps will like having them as a hover to show exactly when something was done (IE when exactly did I save this comment?). Its not a good idea to change those back, as we'd only lose potentially useful info.

Field names should be simplified to be as before, ie banned instead of received_ban, is_moderator instead of became_moderator etc.

Not a big issue to me, but I like the current language since it shows that these are actions taken, not always current states.

Structs like instance_actions are nullable, which makes it impossible to explore the API by browsing the site and observing requests in browser dev tools. This means that client devs need to check the documentation every time, which makes development unnecessarily complicated. We should change it so that if no db row instance_actions exists, a default value is returned with null/false values.

They would only have to do this if they incorrectly defined the type any didn't account for optional fields in the API client (or trying to browse the bare JSON objects). I don't like the idea of inserting fake action rows where none exist. If you use any language library (like lemmy-js-client), this is simple to account for : community_view.instance_actions?.received_ban.

I don't know of any language this is going to be a problem for, we already have tons of optionals in the API.

Fields community_id, person_id etc are unnecessary for clients and can be marked serde(skip), or even completely removed from the Rust structs.

I'm fine with skipping those, don't remove them from the structs as they're necessary for reading / inserting oftentimes.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants