Skip to content

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

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

[Feature]: Move checks for asset upload status into server endpoint #731

Closed
bo0tzz opened this issue Sep 21, 2022 · 0 comments
Closed

[Feature]: Move checks for asset upload status into server endpoint #731

bo0tzz opened this issue Sep 21, 2022 · 0 comments
Labels

Comments

@bo0tzz
Copy link
Member

bo0tzz commented Sep 21, 2022

Currently, clients each implement their own logic to decide whether they should upload an asset to the server. After upload, the server then examines the asset again to determine whether it was indeed appropriate to be uploaded. This places copies of the relevant code in multiple places. Instead, the server should expose an endpoint for clients to ask whether a given asset should be uploaded. With that approach, all the relevant code for supported mimetypes and such can exist only serverside.

This endpoint should take an array request objects with metadata about the asset. Some optional?, some required!. I propose the following fields:

  • id! - A unique id by which the client can identify the asset. Used only in the response to this request. (eg ce784cdd-f459-4d94-b557-9dd73d46cc56)
  • extension! - The extension of the asset file (eg .jpeg)
  • mimetype! - The mimetype of the asset file, as determined by the browser or a mimetype library (eg image/jpeg)
  • sha1? - The sha1 hash of the file (93729ce956531f38867f78858023882147cdfe00)
  • deviceId? - The id of the client device (same as current deviceId, maybe for bwcompat?)
  • deviceAssetId? - The id of the file as determined by the client platform (same as current deviceAssetId, maybe for bwcompat?)

In response, the server should send an array with one object for each of the request objects, stating what action the client should take with that asset. Suggested:

  • id! - The unique ID as sent by the client in the request, to identify the asset
  • action! - The action to take on this asset. Accept, Reject (naming tbd? Can also be Upload, Ignore, etc)
  • reason? - If the asset is rejected, the reason why (Unsupported, Duplicate, etc)

Here's an example request and response:
POST /api/v1/asset/prepareUpload

[
  {
    "id": "ce784cdd-f459-4d94-b557-9dd73d46cc56",
    "extension": "png",
    "mimetype": "image/png",
    "sha1": "93729ce956531f38867f78858023882147cdfe00"
  },
  {
    "id": "0fc8024b-43fb-436a-8ced-609268858094",
    "extension": "mp3",
    "mimetype": "audio/mpeg"
  },
  {
    "id": "this can be literally any value",
    "extension": "webp",
    "mimetype": "image/webp",
    "sha1": "5e94be3495d080eed4ca8ebe1fc10b2410625d8d"
  }
]

Response:

[
  {
    "id": "ce784cdd-f459-4d94-b557-9dd73d46cc56",
    "action": "Accept"
  },
  {
    "id": "0fc8024b-43fb-436a-8ced-609268858094",
    "action": "Reject",
    "reason": "Unsupported"
  },
  {
    "id": "this can be literally any value",
    "action": "Reject",
    "reason": "Duplicate"
  }
]
@bo0tzz bo0tzz added feature needs triage Bug that needs triage from maintainer labels Sep 21, 2022
@bo0tzz bo0tzz added good first issue Good for newcomers and removed needs triage Bug that needs triage from maintainer labels Nov 2, 2022
@bo0tzz bo0tzz changed the title [Feature]: Server should expose supported content types on upload API [Feature]: Move checks for asset support into server endpoint Feb 4, 2023
@bo0tzz bo0tzz removed the good first issue Good for newcomers label Feb 4, 2023
@jrasm91 jrasm91 changed the title [Feature]: Move checks for asset support into server endpoint [Feature]: Move checks for asset upload status into server endpoint Feb 5, 2023
@immich-app immich-app locked and limited conversation to collaborators Feb 8, 2023
@alextran1502 alextran1502 converted this issue into discussion #1658 Feb 8, 2023

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

Labels
Projects
None yet
Development

No branches or pull requests

3 participants