SVG Image Upload REST API

[nubeio]

SVG Image Upload REST API

[otto-dev]

Ok here NubeIO/dashboard#228

[otto-dev]

EDIT: I previously had described a bug here regarding the update endpoint. As it turns out, the server returns two ID attributes for widget_image entries, namely _id and id, and I was able to resolve the issue by using the right one.

I leave the second issue here, but I can work around it if that's what you advise:

---

Absolute / relative URL inconsistencies

Steps to reproduce the behaviour

When you create or update a widget_image, the server expects a relative URL in the JSON POST body.

But when you request the widget_images (GET {{api_server}}/api/widget_image), then the server returns absolute URLs to the image in the JSON body.

This is a problem because you cannot update a widget_image based in the existing data without first disassembling the image URL and converting it back into a relative URL. Otherwise you end up with image URLs like this after updating, for example, a title:

image: "http://45.76.112.85:8085http://45.76.112.85:8085/media/..."

It also makes setting external URLs impossible.

Expected behaviour

The server should always set and return the URL as provided by the client without transforming it.

You could work around it, but since the update endpoint needs to be fixed anyway, might as well fix this one too

[RaiBnod]

Hello Iggy,

Please find list of the endpoints:

1. POST: {{api_server}}/api/upload_image (for saving image)
2. GET: {{api_server}}/api/widget_image (for getting all widget_images)
3. GET: {{api_server}}/api/widget_image/{id} (for getting specific widget_image)
4. POST: {{api_server}}/api/widget_image (for creating new widget_image with its metadata)
5. PUT: {{api_server}}/api/widget_image/{id} (for replacing a widget_image with new values)
6. DELETE: {{api_server}}/api/widget_image/{id} (for removing a widget_image from the list)

For saving new widget_image and creating its metadata steps would be like this:

• Getting imagePath: Upload image at first (1), and get imagePath. For example return data will be like this: {"path": "/media/xyz.svg"}
• Save the metadata and image details (4), with the help of the imagePath

Schema example:

{
  "title": "Light Bulb",
  "category": "Symbols",
  "image": "/media/xyz.png"
}

P.S find the link on the postman:

• https://documenter.getpostman.com/view/666859/Rzfgnp1Y#c8983c95-218c-015d-d595-80e1a4911d37

[otto-dev]

Great stuff, thanks! Looks good. If there are any issue when implementing it I'll let you know.

[zero88]

@RaiBnod @otto-dev
Is it work properly after #34 is already merged?
pls verify and close it if issue is resolved.

@RaiBnod Does it need to make new deployment in current server?
Thx

[otto-dev]

I'm going to get back to this once I everything is implemented in the dashboard frontend

[zero88]

Oh, I see.
Could you put a reference link to an issue from dashboard or device-status-visualizer?
Thx

[RaiBnod]

@otto-dev The backend service is working as expected and is already deployed. Please verify from your end.

[RaiBnod]

Yes, use id over _id.

Absolute / relative URL inconsistencies

Those inconsistency can be removed out by using only the relative path. But on frontend we need to append the {{api_server}} for getting those media resource. Will this be okay or we have better way to handle this?

Need your comments.

[otto-dev]

Thanks.

Yes, please just use the relative paths, i.e. the path provided by the frontend.

[otto-dev]

Lastly, I noticed that unused uploaded images will accumulate indefinitely as there is no deletion mechanism for the files. The problem is basically that a JSON entry depends on the existence of an image, instead of the existence of an image depending on a JSON entry (like in the task description). So images can't be deleted at the same time as the entries, but I think it's too late to change that now. If you want, I can call a DELETE endpoint for the image files themselves if an entry is removed. I'll leave it up to you if you think it's necessary.

Other than that, everything works as expected. Good job, and thanks! 👍

[zero88]

I already mentioned this issue here: #24 (comment)

In short, we will send image with absolute url, and include image id, maybe in HTTP header

[otto-dev]

Ok, no problem. Please just document your decisions and changes so that I can implement them in the frontend. Thanks

[zero88]

@otto-dev

the problem is basically that a JSON entry depends on the existence of an image, instead of the existence of an image depending on a JSON entry (like in the task description). So images can't be deleted at the same time as the entries, but I think it's too late to change that now. If you want, I can call a DELETE endpoint for the image files themselves if an entry is removed.

it will be background backend process, frontend doesn't need do anything

[zero88]

@otto-dev In the client side, to avoid blocking your work, pls using workaround to split image path before uploading.
After #38 is done, we will use image_id instead of image_path as currently.
So pls stay tuned..

[RaiBnod]

For making things consistence:

Discussed with @Zero-88 Son, and come up to the solution:

POST: upload_image
Payload: image_name
Create entry in DB with image_id and image_name, image_title (without media path, like 490adcfb-ab29-42cf-80d3-e563fe25ac15image.jpg)
Response: image_id

POST: create_site
Payload: {site: "xx", image_id: "<image_id from the POST: upload_image>"}
Response: "success"

GET: list (All in dashboard overview or something like that) does it need display image in this step or go detail?
Response: image_id or image_absolute_path if need display

GET: detail_page
Response: image_id and image_absolute_path

PUT: ignore image_absolute_path and save it

[otto-dev]

A few weeks ago I had implemented a workaround for the absolute-URL issue as requested and was waiting for an update, but since it seems to work fine with the work-around, from my side this can be closed.

[zero88]

https://github.com/NubeIO/dashboard/issues/274