Closed exejutable closed 5 years ago
Hi, thanks for the PR. Just for me to understand: the idea is that your API has these parameters in every operation, so you want to exclude these from the generated services and pass them via interceptors?
Hello Luis, exactly, the idea is to exclude some parameters that are generally added to an interceptor. Maybe in a future pull request we can generate the interceptor with a flag.
Seems fine. Personally I consider a bad practice to pass these parameters on every operation. Instead, the API can declare a security schema with a header. But it is ok for APIs where one is using, but can't modify. I'll merge it as is, but in future PRs, please, don't set a new version in package.json. Even in this case, it is a new functionality, not a bug fix, so the correct version would be 0.3.0, not 0.2.6.
Seems fine. Personally I consider a bad practice to pass these parameters on every operation. Instead, the API can declare a security schema with a header.
Yes, is a bad practice, that was a example, in my case is for multitenancy, my spec sends a multitenancy token in all operations.
But it is ok for APIs where one is using, but can't modify. I'll merge it as is, but in future PRs, please, don't set a new version in package.json. Even in this case, it is a new functionality, not a bug fix, so the correct version would be 0.3.0, not 0.2.6.
Yes i know this is a minor feature based on semantic version, but idk how you manage the versions, some repositories use the minor like a major. I'll keep that in mind for the next time.
Best regards!
This functionality is very useful when you have interceptors in the angular app for some headers like
Tenant-Code
orX-Authorization
and dont need to pass it to the service methods.Angular Interceptors Documentation