-
Notifications
You must be signed in to change notification settings - Fork 29
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
Modify endpoints in own server section of AWS S3 #214
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for making a PR.
Now that I think about it, does it make sense to duplicate endpoints of the example? I feel like it's just likely to get out of date again.
Some alternatives:
- Instead of writing the endpoints and a link the example root, we can also create to steps:
- Or we keep the HTTP methods but remove the specific endpoints and add a sentence above that you need you need these endpoints but it's up to you to decide under which route they fall, as long as you keep it in sync with Uppy.
What do you think?
I'm still getting familiar with the available Uppy components. These endpoints will only change if I think Also, |
No we are updating the section on using it with your own server. At the moment the endpoints don't matter at all. For instance in As discussed before we should change the property name from |
From a user's point of view, I think the first option would be better. |
Would you like to make the change? |
I will update this PR later today. I can only work on it outside of European working hours. |
The first PR to change the endpoints in the documentation.
https://github.com/transloadit/uppy/blob/960362b373666b18a6970f3778ee1440176975af/packages/%40uppy/companion/src/server/controllers/s3.js#L439-L447
Related to #213