[Typescript][Angular] Response headers are not available.

[HermenOtter]

Description

I want to access the response headers for an E-tag. For my current swagger yaml file, it doesn't generate anything to access it. This is the same issue it is supposedly fixed, but in my current generated code base I cannot find the withHttpInfo methods, are they removed in a newer version? Or am I doing something wrong?
@wing328

Swagger-codegen version

master (commit f78d958 ))

Swagger declaration file content or url

path:
    parameters:
    ............
    get:    
      .............
      produces:
      - "application/json"
      .............
      responses:
        200:          
          headers:
            ETag:
              type: string
          schema:
            ............         

 public get(......params..): Observable<any> {
        if (parm=== null || param=== undefined) {
            throw new Error('error.');
        }
        let headers = this.defaultHeaders;

        return this.httpClient.get<any>(`${this.basePath}...path...}`,
            {
                headers: headers,
                withCredentials: this.configuration.withCredentials,
            }
        );
    }

Suggestion

There is a way to fix it with the new httpclient.
@kenisteward

[kenisteward]

So it is possible with the addition of 4.3 http client that the generation of those method were removed for that type. I'll look into this when I get to my computer

…

On Wed, Nov 8, 2017, 4:03 AM Hermen Otter ***@***.***> wrote: @kenisteward <https://github.com/kenisteward> — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#6902 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AMPLtX4lduTcABCAX47Xcx3p9anwRvP9ks5s0W58gaJpZM4QU8xm> .

[kenisteward]

@HermenOtter looking at the example you gave it looks like no fix is needed. All you do is subscribe to the observable it returns and then inspect the response. Am I missing something?

With the old http module because it returned the json() straight up we needed the extra function. Now with the http client that allows us to check out the headers without the need of that extra function.

[HermenOtter]

@kenisteward Thank you for your fast response.
The problem is: that the current method only returns the body and not the body and the headers.

this.service.getSubject(this.subjectId).subscribe(
        result => { this.subject = result; console.log(result.headers);

This logs: undefined.

I read that you first need to define the observe parameter as "response" to retrieve the headers and body.

As you can see the default value for observe? is "body".

However if you change the httpclient to return the "response", you still need to make decisions on how to structure the code, an extra method might still be required? Maybe the author of the 4.3 httpclient can give some insight on choices made?

@wing328 @bedag-moo any thoughts?

[wing328]

cc @TiFu @taxpon @sebastianhaas @kenisteward @Vrolijkx

[kenisteward]

@HermenOtter what if we just allow a final argument that allows you to set that field.

I think what we can do to keep it simple is allow an extraclientoptions field and object.assign that without needing to generate a whole other function. By default we set return to body so we don't break current code using it and then per call you can set if you want the full response or not.

[HermenOtter]

@kenisteward I thought of that solution as well, in the first instance I thought returning the object would be a problem(because of the interface of the model), but I tested the solution and I was mistaken.

This works with a bloated if statement:

public getSubjectByNr(id: number, fullResponse: boolean = false): Observable<any> {
        if (id === null || id === undefined) {
            throw new Error('Required parameter subjectnr was null or undefined when calling getSubjectByNr.');
        }

        const headers = this.defaultHeaders;

        if (fullResponse) {
            return this.httpClient.get<any>(`${this.basePath}/subj/v1/subjecten/${encodeURIComponent(String(id))}`,
                {
                    observe: 'response',
                    headers: headers,
                    withCredentials: this.configuration.withCredentials,
                }
            );
        } else {
            return this.httpClient.get<any>(`${this.basePath}/subj/v1/subjecten/${encodeURIComponent(String(id))}`,
                {
                    headers: headers,
                    withCredentials: this.configuration.withCredentials,
                }
            );
        }
    }

Used as

 this.service.getSubjectByNr(this.subjectNr, true).subscribe(
        result => { this.subject = result.body; console.log(result.body); console.log(result.headers);  }
        , error => console.error(error));

I can confirm that the logged body and headers are correct.

[kenisteward]

@HermenOtter

Unfortunately, the reason it works is that we are returning Observable instead of Observable;

We could do something like Observable<ModelReturnType || Response> that way we don't break typings and still get the actual type to cast as.

Also, I was thinking something a bit more simple bloat wise.

2 options

// first option just let the user pass what they want back
public getSubjectByNr(id: number, observe: string = 'body'): Observable<any> {
        if (id === null || id === undefined) {
            throw new Error('Required parameter subjectnr was null or undefined when calling getSubjectByNr.');
        }

        const headers = this.defaultHeaders;

            return this.httpClient.get<any>(`${this.basePath}/subj/v1/subjecten/${encodeURIComponent(String(id))}`,
                {
                    headers: headers,
                    withCredentials: this.configuration.withCredentials,
                    observe
                }
            );
       
    }

second option:

// do like we do now and allow the user to overwrite the full http options except this will be for client
public getSubjectByNr(id: number, extraHttpClientOptions?: any): Observable<any> {
        if (id === null || id === undefined) {
            throw new Error('Required parameter subjectnr was null or undefined when calling getSubjectByNr.');
        }

        const headers = this.defaultHeaders;

       const reqOptions = {
            headers,
            withCredentials: this.configuration.withCredentials
}

          // in the extras you can overwrite whatever you want
         // extra options defined here https://angular.io/api/common/http/HttpClient
          Object.assign(reqOptions, extras);


            return this.httpClient.get<any>(`${this.basePath}/subj/v1/subjecten/${encodeURIComponent(String(id))}`, reqOptoins);
       
    }

I think the second way would be more suitable for a bigger audience. Either way, the fix would be easy and I believe I could have the fix in today If i got the time.

If we wanted to get even more spiffy we could allow it as a configuration value as well so the assignment value could end up being

  observe: observe || this.configuration.observe || 'body'

that way you could set your entire app to return the same thing if that mattered.

[HermenOtter]

@kenisteward First option is a good simple fix. However the second option gives power back to the developer and fixes the problem as well, it seems like a really nifty solution!

About a global configuration, if you can prioritize observe method parameter > global observe > body, as you stated above that would be great. Though the problem with that implementation is that it isn't as future proof as adding extraHttpClientOptions to the global configuration, for example when the angular http options change or you might have to add every option manually to the template if an user requests it when an issue pops up. What are your thoughts on adding the extraHttpClientOptions to global configuration?

[bedag-moo]

Ah, that's what that withHttpInfo method was for!

My apologies, I could not imagine why one might need this, so I didn't implement this method when writing the new code generator using the httpClient.

As for fixes: Kenis solutions are not quite type safe, and solution 1 would be a breaking change, because

const x: Observable<Issue> = issueService.getIssues();

would no longer compile because Observable<Response> is not assignable to Observable<Issue>.

I recommend an overloaded method signature, like the one the httpClient itself uses. To avoid a breaking change, the new parameter should be optional and default to body.

[kenisteward]

@bedag-moo

const x: Observable<Issue> = issueService.getIssues();

works if we define .getIssues() like:

getIssues() : Observable<Response | Issue>

which was in the preface of my solution :P

[kenisteward]

@bedag-moo @HermenOtter I would be interested in exploring the option of using
https://www.typescriptlang.org/docs/handbook/functions.html that angular uses as was pointed out. It may be a much more elegant solution to Union types.

[bedag-moo]

It does not work for me; Typescript 2.4.2 says:

src/app/edit-issue.component.ts(36,15): error TS2322: Type 'Observable<Issue | Response>' is not assignable to type 'Observable<Issue>'.
  Type 'Issue | Response' is not assignable to type 'Issue'.
    Type 'Response' is not assignable to type 'Issue'.
      Property 'id' is missing in type 'Response'.

Might you have tested with mocked up Issue and Response types which are mutually assignable?