share-me
share-me copied to clipboard
Feature Request: Set Title via API Post and return Post URL in API Response
Hello!
I would like to propose the ability to add a title to the post via the same api call that was used to generate it. ShareX allows you to use a variable to define this.
I'd also like the API response to provide the post URL - this is to also put a variable in the ShareX config which will allow it to be easier shared.
Before: API Response:
{
"author": "on2imnwqggminrg",
"collectionId": "tqco9f8weal93h6",
"collectionName": "posts",
"created": "2023-05-20 04:23:05.739Z",
"files": [
"z1qxne4clk31jlw"
],
"id": "p5othop5v4z4k18",
"nsfw": false,
"public": false,
"tags": null,
"title": "",
"updated": "2023-05-20 04:23:05.739Z"
}
After API:
API Response:
{
"author": "on2imnwqggminrg",
"collectionId": "tqco9f8weal93h6",
"collectionName": "posts",
"created": "2023-05-20 04:23:05.739Z",
"files": [
"z1qxne4clk31jlw"
],
"id": "p5othop5v4z4k18",
"nsfw": false,
"public": false,
"tags": null,
**"title": "FileName",**
"updated": "2023-05-20 04:23:05.739Z",
**"PostURL": "https://Share-Me-Domain.com/posts/$id"**
}
This would allow your ShareX config file to be like the following:
{
"Version": "15.0.0",
"Name": "Share-Me",
"DestinationType": "ImageUploader",
"RequestMethod": "POST",
"RequestURL": "https://Share-Me-Domain.com/api/posts",
"Headers": {
"Accept": "*/*",
"Authorization": "TokenHere"
},
"Body": "MultipartFormData",
"Arguments": {
"Title": "{filename}"
},
"FileFormName": "files",
"URL": "{json:PostURL}"
}
Example cURL command
curl --location 'https://share-me-domain.com/api/posts' \
--header 'Accept: */*' \
--header 'Authorization: TokenHere' \
--form 'files=@"/C:/Users/Name/Folder/FileName.png"' \
--form 'title="FileName"'
Hi there! I am working on setting all the post attributes with this endpoint, since I want to migrate the frontend to use it as well, so that should cover "setting title via API POST" but I won't be adding the post URL for simple reason that the backend isn't aware of the frontend's domain/path and it would be an additional environment variable that couples them too much in my opinion.