Use with your own server section of AWS S3 contains misleading routes

[nerg4l]

The routes provided in the "Use with your own server" of AWS S3 uploader shows different endpoints than the endpoints used in the linked "Setup Uppy" example.

uppy.io/docs/uploader/aws-s3-multipart.mdx

Lines 143 to 151 in 6a5a3bc

	- `GET` > `/uppy/sts`: get the temporary security credentials (optional).
	- `POST` > `/uppy/s3`: get parameters and pre-signed URL for non-multipart
	upload.
	- `POST` > `/uppy/s3-multipart`: create the multipart upload.
	- `GET` > `/uppy/s3-multipart/:id`: get the uploaded parts.
	- `GET` > `/uppy/s3-multipart/:id/:partNumber`: sign the part and return a
	pre-signed URL.
	- `POST` > `/uppy/s3-multipart/:id/complete`: complete the multipart upload.
	- `DELETE` > `/uppy/s3-multipart/:id`: abort the multipart upload.

From the Setup Uppy example:

• /sts
• /sign-s3
• /s3/multipart
• /s3/multipart/${uploadId}
• /s3/multipart/${uploadId}/${partNumber}
• /s3/multipart/${uploadId}/complete

[Murderlon]

They are the same, it just shows that if you have an existing backend, perhaps even with existing s3 endpoints , you can just group them under /uppy route of whatever you'd like to do. When using the options for the s3 plugin you have to write the code manually anyway to call the backend.

[nerg4l]

Are you sure that only the prefix is different?

• /uppy/sts
• /uppy/s3
• /uppy/s3-multipart
• /uppy/s3-multipart/:id
• /uppy/s3-multipart/:id/:partNumber
• /uppy/s3-multipart/:id/complete

The documentation uses s3-multipart but the linked code example uses s3/multipart. Also the sign route is completely different.

[Murderlon]

Maybe the docs are misleading, but it just needs to match. You can do this if you want:

On the server:

app.post('/my/supercool/endpoint', (req, res, next) => {}

And then on the client:

const response = await fetch('/my/supercool/endpoint', {
  method: 'POST',
  // Send and receive JSON.
  headers: {
    accept: 'application/json',
  },
  body: serialize({
    filename: file.name,
    type: file.type,
    metadata,
  }),
  signal,
})

It's a lot of manual work. Ideally, we'd have @uppy/server-functions which you can use on the server, and force people to have the same endpoints as companion. Then I think you wouldn't need to manually write this.

[nerg4l]

Agreed, a companion compatible uploader config would be even better.

I was considering this option but could not find any documentation of the current endpoints used by Companion. I can dig through the code of course but I would prefer to have it in a more readable way.

[Murderlon]

I created two issues for it:

• Introduce @uppy/server-functions uppy#5033
• When using aws-s3, force endpoints to be the same as Companion to simplify setup uppy#5030

In the meantime if you're willing to contribute a PR to make the writing more clear in the current docs that would be great :)