Repair swagger

[cmharlow]

Regenerating API code to work. Removed status from Resource model, since status isn't yet determined as something the API code needs to be aware of.

Dependencies (UUID library) are missing from this PR (are getting put into $GOPATH via go get and not into dep ensure) that need to be documented and added. We also have a dep / aws-sdk for go conflict. Opened issues #75 #74 for these, respectively.

[cmharlow]

Also moves up in priority #42 and #73 (not just dep version, but go-swagger version)

[jcoyne]

I don't agree that this is the correct response for a create. As documented on the whiteboard the response should be a RequestID, a ResourceID and a RequestStatus. I don't think it makes sense to send them back the resource they just sent us. See #44

[jcoyne]

I'm curious to know what you mean about the UUID library being missing. I see it in the lockfile right here: https://github.com/sul-dlss-labs/taco/blob/master/Gopkg.lock#L156-L159

[cmharlow]

It wasn’t in the toml file for me to then ensure off of. Can confirm again when at a computer.

…

On Jan 25, 2018, 8:49 PM -0800, Justin Coyne ***@***.***>, wrote: I'm curious to know what you mean about the UUID library being missing. I see it in the lockfile right here: https://github.com/sul-dlss-labs/taco/blob/master/Gopkg.lock#L156-L159 — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.

[jcoyne]

@cmh2166 are we certain it needs to be in the toml file? I thought that was just for the ones it can't introspect. The true list of dependencies is in the .lock file.

[cmharlow]

Check the docs around dep ensure -update: https://golang.github.io/dep/docs/daily-dep.html

[jcoyne]

@cmh2166 yeah on that page I'm seeing:

Of course, given this model, you don't have to use dep ensure -add to add new dependencies - you can also just add an appropriate import statement in your code, then run dep ensure. However, this approach doesn't always play nicely with goimports, and also won't append a [[constraint]] into Gopkg.toml. Still, it can be useful at times, often for rapid iteration and off-the-cuff experimenting.

So I'm wondering what the drawback to this approach is. This also seems to be what one of the maintainers recommends as her preferred workflow: golang/dep#376 (comment)

[cmharlow]

@jcoyne i'm not commenting on the approach against, i'm saying we don't do that cleanly right now (hence your original PR adding all this dynamo stuff not working when I pulled down and only ran dep ensure).

Regardless, that is ticketed and does not stop this PR.

[cmharlow]

Closing ticket given recent updates. Doesn't close issues related since those are still undetermined (and the code / spec still need cleaning up).