Issue #3851: Bindings require endpoint href instead of resource href - Pulp

Actions

Send by e-mail Copy link

Issue #3851

closed

Bindings require endpoint href instead of resource href

Added by daviddavis over 6 years ago. Updated over 4 years ago.

Status:

CLOSED - CURRENTRELEASE

Priority:

Normal

Assignee:

dkliban@redhat.com

Category:

Sprint/Milestone:

3.0.0

Start date:

Due date:

Estimated time:

Severity:

2. Medium

Version:

Platform Release:

OS:

Triaged:

Yes

Groomed:

Sprint Candidate:

Tags:

API Bindings, Katello

Sprint:

Sprint 42

Quarter:

Description

We patched the bindings so that if there are any path variables in the url (e.g. /repositories/<repo_pk>/versions/<number>/content/) you have to instead pass in the entire href you want to call. Here's an example:

from swagger_client.api.repositories_api import RepositoriesApi
api = RepositoriesApi()
api.repositories_versions_content("/repositories/1/versions/1/content/")

Notice how I have to construct the href I am calling. Here's how I would expect the bindings to work:

from swagger_client.api.repositories_api import RepositoriesApi
api = RepositoriesApi()
api.repositories_versions_content("/repositories/1/versions/1/")

Notice that I am using the repo version href and not the endpoint that the bindings are actually calling.

Actions

Copy link

Updated by CodeHeeler over 6 years ago

Triaged changed from No to Yes
Sprint set to Sprint 40

Actions

Copy link

Updated by daviddavis over 6 years ago

Sprint/Milestone set to 3.0.0

Actions

Copy link

Updated by daviddavis over 6 years ago

Tags API Bindings added

Actions

Copy link

Updated by jsherril@redhat.com over 6 years ago

Tags Katello-P1 added

Actions

Copy link

Updated by bmbouter over 6 years ago

I'll try to answer the question in the ticket about how the user will get that href. The user was given that string when the repo version was created. Then they use it with the bindings to make an object they can interact with.

Also this is consistent with how all bindings work, even those that have IDs. If an object had id 123456, the user would have had to receive 123456 from a server response at some point. Only by saving that response can they have the ID 123456 to use with the bindings to make an object they can interact with. So the decision of a url isn't creating or solving any problems specifically.

I want to state the value in the bindings as I see them to see what others think. I believe the value of the bindings is in their language-native usefulness after they are instantiated. What string you hand them to instantiate the objects I don't think affects that value.

I believe the right resolution is to close as NOTABUG. If it does stay on the sprint, I believe it needs to go through sprint planning again because it's not clear what the expected resolution is.

Actions

Copy link

Updated by daviddavis over 6 years ago

bmbouter, thanks for the response. I think the bug is unclear so let me give an illustration that might help clarify this bug. Here's how you call the repo version method in the bindings today:

api.repositories_versions_content("/repositories/1/versions/1/content/")

Notice that I have to supply the url to the endpoint including /content/ component.

What I would expect is that I be able to call the function with the repo version identifier or href:

api.repositories_versions_content("/repositories/1/versions/1/")

In other words, currently you have to supply the href to the endpoint you are calling instead of the href to the resource you are interacting with (e.g. repo version).

Let me know if that's still not clear. I'll update the bug title and description.

Actions

Copy link

Updated by daviddavis over 6 years ago

Subject changed from The bindings require users to know the href they are calling to Bindings require endpoint href instead of resource href
Description updated (diff)

Actions

Copy link

Updated by dkliban@redhat.com over 6 years ago

This is a bug with how the bindings are currently being generated. Thank you for explaining it @daviddavis. There are 2 ways to resolve this issue: update swagger-codegen or update our OpenAPI schema to work with upstream swagger-codegen. I've started a discussion about this on the list[0]. bmbouter please provide feedback on the list also.

[0] https://www.redhat.com/archives/pulp-dev/2018-July/msg00071.html

Actions

Copy link