search

joyent / kosh

Second-generation shell for accessing the Conch API
Mozilla Public License 2.0
2 stars 5 forks source link

API wrappers for Create endpoints (POSTS that return a redirect) should return the redirected data #89

Open perigrin opened 3 years ago

perigrin commented 3 years ago

Currently we ignore a redirect on create because it was simpler to implement. We should instead follow the redirect and do the lookup then return the data.

This will be a breaking change for the conch library code so needs to happen in 4.x.

karenetheridge commented 3 years ago

is this really needed? If the shell doesn't need to see the new/changed data it doesn't need to follow the redirect, and that will save the api a needless query.

Last year I wanted to change all the 303 + URI responses to 201 and Location header, but sungo complained because the shell at that time expected to follow all redirects. Now that that constraint has been removed, do we need to bring it back?

perigrin commented 3 years ago

I’m happy to have 201 + Location headers. For kosh this is only necessary because the racks can be created without knowing their UUID but I seem to only be able to look them up with their UUID which may be a bug to report to you after I dig some more.

That said I almost invariably do a second GET almost immediately after issuing a create from the cli so I can provide feedback to the user that their action did something. Probably either have that step be optional (e.g. new wrapper methods that do the fetch) or return the URI (or just the relevant bits) instead of doing the fetch automatically.

karenetheridge commented 3 years ago

I believe all Location headers (used for both 201 and 303 responses) contain the canonical identifier for the resource, which would contain its UUID (there was one outlier that i fixed a few months ago where POST /hardware_vendor would return the name, not the uuid). However, unless kosh automatically follows 303 redirects, the response is the same either way - it's a Location header in both cases.

perigrin commented 3 years ago

Either way I’m currently throwing away the results. I think I’d prefer a 201 and then I can make it so with the Go API you can choose if you want to follow or not.