Refitter tracks local specification file rather than remote service specification

[dammitjanet]

Is your feature request related to a problem? Please describe. When adding a refitter for a remote service, the resulting refitter json file references the local copy of the service specification, rather than the remote service specification.

Describe the solution you'd like Given that in most cases, changes to the remote service are out of the developers hands, updating the service specification json file would require that either

1. the json file is edited manually (not good)
2. the json is replaced manually with a copy of the remote service specification (not good)
3. the refitter has to be removed and re-added (again, not good)

I think the refitter should track the remote specification over the local copy, or at the least have a reference to the remote source at which point things become much more interesting from a development standpoint.

Describe alternatives you've considered If the refitter tracks only the remote service specification, then there is no need to keep a local copy of the service specification, however I always find it useful to know when a remote service has changed, and keeping a copy of the specification file around, seems to me a good idea

if the refitter tracks the local specification (as it does now) and the remote specification, then updated the refitter would fetch the remote specification and overwrite the local specification json.

Additional context

it might be useful to open the Discussion portion of Github for this project, as I think it does need discussion on what the ramification of this kind of change would bring.

[christianhelle]

@dammitjanet thanks for taking the time to bring this up

When adding a refitter for a remote service, the resulting refitter json file references the local copy of the service specification, rather than the remote service specification.

I have thought about this I wanted to implement it so that the behavior is aligned with working with NSwag Studio files. This is trivial to implement and I will likely go in this direction.

Given that in most cases, changes to the remote service are out of the developers hands, updating the service specification json file would require that either

1. the json file is edited manually (not good)
2. the json is replaced manually with a copy of the remote service specification (not good)
3. the refitter has to be removed and re-added (again, not good)

It's also possible to right-click on the JSON/YAML file and select Run Custom Tool, not the best solution and it's in no way intuitive either. You can also right-click on the .refitter file and select Generate Refitter output

I think the refitter should track the remote specification over the local copy, or at the least have a reference to the remote source at which point things become much more interesting from a development standpoint.

It's not easy to track changes to a remote resource without polling the remote resource and doing so will degrade Visual Studio. If an extension is using CPU/RAM more than what Visual Studio thinks it should use then Visual Studio will recommend the user to disable the extension, and that would not be an ideal experience.

An alternative is to do it on build-time (or pre-build time) and I have toyed with the idea of implementing MSBuild tooling on top of Refitter that checks for existing .refitter files and re-generates an API client at pre-build time I haven't looked into this in detail for this so I'm not sure exactly what's possible

it might be useful to open the Discussion portion of Github for this project, as I think it does need discussion on what the ramification of this kind of change would bring.

Done. I always thought it was enabled as I could always see the tab since I own the repo. I didn't know I had to click the Get Started button to enable it for others! Thanks for pointing this out

[christianhelle]

Thank you so much for this input @dammitjanet

This tool has a rather large user base but unfortunately, I hardly hear anything from my users

[dammitjanet]

Ok what about still using the local source for the VS Tool to work with, so it doesn't start whining about tracking a remote source. We then add an additional field to the refitter configuration which i'd describe as OriginalOpenApiPath as opposed to the OpenApiPath.

This would then advise refitter under specific circumstances (say when you right click the refitter file and Generate Refitter output), it would update the specification json with the remote content and then allow refitter to do its work.

That way the VS Tool wouldn't balk all the time, and the functionality would be there to update the specification schema from a remote source.

It might even be easier to pop up a window after the Generate Refitter output option is clicked, if the refitter file contains the new field outlined above and give the user the option to update from the original source over regenerating from the stored specification json file (which in this use case should already be up to date)

[christianhelle]

@dammitjanet I'll look into what API's are accessible for Visual Studio extensible for background jobs. There may be something interesting and new that I don't know about.

It might even be easier to pop up a window after the Generate Refitter output option is clicked, if the refitter file contains the new field outlined above and give the user the option to update from the original source over regenerating from the stored specification json file (which in this use case should already be up to date)

I'm not sure about introducing a new option like OriginalOpenApiPath in the .refitter file format as the OpenApiPath can point to a remote resource, and if so then Refitter will work with the remote resource.

I can change the behavior of Right-click Project/Folder -> Add New REST API Client -> Refitter not to create a JSON/YAML and instead create a .refitter file pointing to the URL entered in the popup dialog. This way the local file problem goes away by itself. Does that work for you @dammitjanet?

[dammitjanet]

I can change the behavior of Right-click Project/Folder -> Add New REST API Client -> Refitter not to create a JSON/YAML and instead create a .refitter file pointing to the URL entered in the popup dialog. This way the local file problem goes away by itself. Does that work for you @dammitjanet?

yup, it should. You could probably still create the json spec file and update it when the refitter runs, but not "link" it in the way that it currently is. Would that be too hard, or would it still causes issues?

[christianhelle]

yup, it should. You could probably still create the json spec file and update it when the refitter runs, but not "link" it in the way that it currently is. Would that be too hard, or would it still causes issues?

Yeah, that's also possible. But it wouldn't really have much value, expect if the user wants to experiment with different code generates by doing a right-click on the JSON/YAML file and selecting another generator

like this:

[christianhelle]

@dammitjanet I think I'll build this feature in the next couple of days when I find the time. The nice pre-summer weather in Copenhagen isn't exactly the best motivation for getting some coding done 🌞 🏖️

[dammitjanet]

lucky you, is raining extremely hard in the north of England