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

Way to Forms 5 #2041

Open
7 tasks
Chartman123 opened this issue Apr 2, 2024 · 5 comments
Open
7 tasks

Way to Forms 5 #2041

Chartman123 opened this issue Apr 2, 2024 · 5 comments
Labels
discussion Being discussed enhancement New feature or request overview Overview of other issues technical debt Technical issue
Milestone

Comments

@Chartman123
Copy link
Collaborator

Chartman123 commented Apr 2, 2024

This is a collection of tasks needed for preparation/release of Forms v5.

4.3 release:

5.0 release:

  • Remove legacyLink related code
  • Remove deprecated endpoints in API
  • ...
@Chartman123 Chartman123 added the overview Overview of other issues label Apr 2, 2024
@Chartman123 Chartman123 added this to the 5.0 milestone Apr 2, 2024
@Chartman123 Chartman123 added enhancement New feature or request 1. to develop Accepted and waiting to be taken care of technical debt Technical issue labels Apr 3, 2024
@susnux
Copy link
Collaborator

susnux commented Apr 15, 2024

How about unifying our API? Currently there is not really a pattern in the API routes - especially logical nesting.

For example for forms:

What Current New
Get forms GET /forms GET /forms
New form POST /form POST /forms
Get form GET /form/:id: GET /forms/:id:
Clone form POST /form/clone/:id: POST /forms/:id:/clone
Update form PATCH /form/update PATCH /forms/:id:
Transfer ownership POST /form/transfer - (just use the patch)
Delete form DELETE /form/:id: DELETE /forms/:id:

This is just an example, but I think it would make the API more logical

@Chartman123
Copy link
Collaborator Author

Yes I think this would definitely make sense... This was always something illogical to me

@susnux
Copy link
Collaborator

susnux commented Apr 16, 2024

I do not see any use case for the hash other than the legacy link, probably we can also remove that with v5?

@Chartman123 Chartman123 added the discussion Being discussed label Apr 16, 2024
@Chartman123 Chartman123 pinned this issue Apr 16, 2024
@Chartman123
Copy link
Collaborator Author

Should we add the newly organized endpoints already in 4.3 so that users of the API can already adapt to the new structure?

And regarding the hash: If we remove it, our internal links/URLs would only have the id, right? I think we should at least have a look at the APIs so that we don't mix it there (sometimes hash is needed, sometimes the id).

@Chartman123 Chartman123 removed the 1. to develop Accepted and waiting to be taken care of label Apr 16, 2024
@susnux
Copy link
Collaborator

susnux commented Apr 20, 2024

And regarding the hash: If we remove it, our internal links/URLs would only have the id, right? I think we should at least have a look at the APIs so that we don't mix it there (sometimes hash is needed, sometimes the id).

Yes I would just use the form id, like for files. if you use the internal share link it is just the file id.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
discussion Being discussed enhancement New feature or request overview Overview of other issues technical debt Technical issue
Projects
None yet
Development

No branches or pull requests

2 participants