github icon indicating copy to clipboard operation
github copied to clipboard

add support for deployments API endpoints

Open goedelsoup opened this issue 5 years ago • 9 comments

This is still WIP to some degree. We need to determine the best pathway to pass the custom media types for some endpoints. I'm open to following whatever direction you see fit.

goedelsoup avatar Sep 10 '19 14:09 goedelsoup

What happens if you put an explicit EntityEncoder in the companion object, I think that would have higher priority than the import so should be used automatically.

ChristopherDavenport avatar Sep 10 '19 14:09 ChristopherDavenport

I thought that'd work but it looks like the GET requests also require overriding the default Accept media type. How about just allowing the user to pass explicitly at the endpoint call site? That would allow the API to support whichever version they would like.

goedelsoup avatar Sep 10 '19 16:09 goedelsoup

Explicitly pass the header?

ChristopherDavenport avatar Sep 10 '19 16:09 ChristopherDavenport

def runRequestWithNoBodyAccept(
   ...,
   acceptHeader: Header
)

Seems messy if we need more things, but could be useful as the escape hatch for git patch/diff etc as well.

ChristopherDavenport avatar Sep 10 '19 16:09 ChristopherDavenport

I was thinking along the lines of acceptHeader but instead creating an ADT over the media types they use.

goedelsoup avatar Sep 10 '19 16:09 goedelsoup

I don't think it ended up too ugly and should be flexible enough for future experimental endpoints.

goedelsoup avatar Sep 10 '19 18:09 goedelsoup

Hmm, any reason the user needs to know about the media type? It seems we could limit the calling the accept stuff to only need to be used by the particular endpoints. But maybe you need multiple per endpoint. I haven't played with this approach too much.

ChristopherDavenport avatar Sep 11 '19 13:09 ChristopherDavenport

Yeah, unfortunately some of these deployment endpoints support up to three different media types, all with different behaviors. We could simply go with the broadest one. Here that would work, because it just leads to less Nones being returned but I'm not certain it holds across other workflow endpoints.

goedelsoup avatar Sep 12 '19 19:09 goedelsoup

Alright, I'm convinced. Wish I didn't have to think like this because I'm lazy, but sounds good.

ChristopherDavenport avatar Oct 02 '19 19:10 ChristopherDavenport