search

ITISFoundation / osparc-issues

🐼 issue-only repo for the osparc project
3 stars 5 forks source link

Update API endpoint to return more info about images #202

Closed KZzizzle closed 4 years ago

KZzizzle commented 4 years ago

Documentation is here: https://documenter.getpostman.com/view/8986837/SWLh5mQL?version=latest

user stories:

Acceptance criteria:

I have a few questions about the data returning from the Biolucida SPARC API. These questions will inform how the ticket is completed on our end.

  1. Are we able to get any additional information from the GET /imagemap/search_dataset/:dataset_source/:dataset_id endpoint? Right now it is returning image_id and share_link. As is, the app will need to make two additional calls per image to get more information to display, one for the thumbnail, and one for the GET /image/:id endpoint to get its metadata. Would we be able to get the response that comes back from Get /image/:id to be included in this original response, and then we would only have to make an additional a request for each images thumbnail?
  2. The GET /thumbnail/:imageId endpoint looks like it is the only GET endpoint that requires authentication. Is this able to take the token as an optional parameter to match the other endpoints?

edit: With the exception of the authentication on the GET endpoint, we can also create an API endpoint that does #1 for us on the server so the client doesn't have to take care of it. (edited)

The response below is the ideal response from the GET /imagemap/search_dataset/:dataset_source/:dataset_id endpoint. This will be what is used to power the Images tab on a Dataset's page. The addition of thumbnail_url and sourcepkg_id will allow us to do the following:

1) thumbnail_url - display a list of thumbnails in the images tab for the users to click on to navigate to the file's page with the viewer on it. 2) sourcepkg_id - used in the URL for the file's page, that then will requests GET /imagemap/sharelink/:sourcepkg_id/:dataset_id to get the sharelink, which will be used to display the viewer.

The ideal response of the API would be: { "status": "success", "discover_dataset_id": "43", "dataset_images": [ { "image_id": "1105", "share_link": "https://sparc.biolucida.net/image?c=MTEwNS1jb2wtMTA4", "thumbnail_url": "", "sourcepkg_id": "" }, ... ] }

KZzizzle commented 4 years ago

➤ MBF SPARC commented:

Joost Wagenaar since the thumbnail image is not stored on Blackfynn, you want the sourcepackageid for the image that it relates to, correct?

KZzizzle commented 4 years ago

➤ Joost Wagenaar commented:

No, I imagine that it would be the url that points to the thumbnail so the portal can render the thumbnail. Cameron Baney can you chime in?

KZzizzle commented 4 years ago

➤ Cameron Baney commented:

Yes, ideally it would be a URL that points to the thumbnail so the portal can render the thumbnail. Otherwise, we'll have to make a separate endpoint call for each thumbnail given a sourcepackageid.

KZzizzle commented 4 years ago

➤ MBF SPARC commented:

thumbnail images do not have a sourcepackageid. the image that was used to generate the thumbnail does, however. you want that returned. correct?

KZzizzle commented 4 years ago

➤ Jeremy Lecoeur commented:

MBF SPARC Ideally, if the endpoint can be modified to also return a thumbnail URL for that image that would be amazing.

Current:

{ "status": "success", "discover_dataset_id": "43", "dataset_images": [ { "image_id": "1105", "share_link": "https://sparc.biolucida.net/image?c=MTEwNS1jb2wtMTA4" }, ... ] }Desired:

{ "status": "success", "discover_dataset_id": "43", "dataset_images": [ { "image_id": "1105", "share_link": "https://sparc.biolucida.net/image?c=MTEwNS1jb2wtMTA4", "thumbnail_url": "https://sparc.biolucida.net/image/123.jpg", "sourcepkg_id": "" }, ... ] }

KZzizzle commented 4 years ago

➤ MBF SPARC commented:

Jeremy Lecoeur Can you let me know what the design is for the images? Last I knew there was no wireframe or design plan that Gazelle had weighed in on?

KZzizzle commented 4 years ago

➤ Leonardo Guercio commented:

Abby Paulson Does it make sense to assign this ticket to representatives from MBF, DAT-Core, and Gazelle?

KZzizzle commented 4 years ago

➤ Abby Paulson commented:

There's no clear user story written for this ticket, but rather just the input of thoughts. Can you or Jeremy Lecoeur or MBF SPARC develop a User story and Acceptance criteria and input that at the top of the description, per the process? An element of Acceptance criteria would be to include a design for the images I would imagine.

With the user story defined and the acceptance criteira, the next step should be clearer.

KZzizzle commented 4 years ago

➤ MBF SPARC commented:

Abby Paulson i agree and have asked for the design plans numerous times and offered my feedback on the topic, including here: https://www.wrike.com/open.htm?id=473117375 - note the screenshot i posted March 3rd. as it is though, MBF has created the requested API call for this different method of thumbnail retrieval [thumbnail retrieval was possible previously as well, but never implemented on the SPARC Portal]. this feature is now ready to test. The Metadata is a separate issue, and should be treated as such. it also requires planning since depending on design could come from multiple places.

KZzizzle commented 4 years ago

➤ Jeremy Lecoeur commented:

MBF SPARC Confirmed that the API has been updated as requested, but the URL returned for the thumbnail is still under an authentication layer which was another part of the ticket ( "I'd like for the GET /thumbnail/:imageId to not require authentication"). Is the expectation for the Portal to use credentials to create a token and hit that URL?

KZzizzle commented 4 years ago

➤ MBF SPARC commented:

Jeremy Lecoeur While you can authenticate as a guest user for API calls to the Biolucida SPARC system, we recommend as a best practice that you use the token returned by POST /authenticate whenever possible. This token only needs to be generated once while the system is in use, only invalidating after an hour of inactivity. The reason we recommend this approach is twofold: our telemetry is able to log user requests more accurately when they're made by an authenticated user, and it's simply easier to work with the system assuming you'll always attach a token (when possible). In short, if you have the ability to attach a token, the system will always work better with one. If you need your login creds again, just shout!