HTTP Client Plugin Interface

[jimkring]

About
This is a user story describing the needs for a new HTTP Client Plugin Interface feature, which will guide feature design and implementation.

Key Links

• HTTP Client Plugin Interface #31 (main discussion and prototype code)

Summary
Users can configure which HTTP Client implementation the REST Client uses, via an http-client plug-in interface.

Background
Currently (in 2.x and earlier), the REST Client uses LabVIEW's built-in HTTP Client, which has various limitations. To overcome such limitations, it is desirable to allow users to choose different http-client implementations (e.g. NI Advanced HTTP Client, .NET HTTP Client, etc.) to be used with the REST Client.

Goals

• Users are able choose/create specific HTTP client implementations that meet their project needs (possibly to work around limitations/bugs/incompatibilities in existing implementations)
• Users do not have to make any changes to their existing applications, aside from the REST Client initialization/configuration steps in their code.
• Users can dynamically configure which http-client implementation is used by the REST Client, to create their own components that accept an http-client plugin.
• Plug-in Interfaces should be open to extension in the future -- for example, in the future we would like to be able to support async requests, follow redirects, etc.

Additional Outcomes

• As part of the development of this functionality, a more reusable library of interfaces for requests, responses, sessions, dictionaries, etc. evolves, which can become its own library for use in other packages.

Next Steps

• merge main into develop (so we can start making PRs into develop) #36
• create plug-in interfaces for http-request, http-response, http-headers #37
• add docs that describe how to create a plug-in (and plug-in architecture overview) #38
• add tests that verify functionality of the REST Client and the various http-client plug-ins #39
• add ni-advanced-http-client #40
• add dot-net-http-client #41
• Create "Pure G" example http client #42

[jimkring]

@francois-normandin I added the goal "Plug-in Interfaces should be open to extension in the future -- for example, in the future we would like to be able to support async requests, follow redirects, etc." -- let me know if you agree and/or would reframe/rephrase that.

[francois-normandin]

@jimkring Agreed!

[jimkring]

@jyoung8711 This user story is based on your feedback. Please LMK if you’d add or change anything. Thx!

[jyoung8711]

@jimkring -- I saw this draft yesterday, and was thinking about it overnight. I like the additional edits, and I think the second "goal" is critical here:

The interface layer can be as complex as it needs to be, but it's important that the wrapper class be as painless as possible to utilize -- as it currently is. It's a "drop in" replacement for the Native HTTP Library, while adding a lot of power. There's a lot of value-add there.

Anecdotally, this was one of the first 3rd party class based libraries I utilized on a regular basis because of how simple it was (along with the JKI JSON library)

One minor consideration I'll add... At one point, I did a conversion of this library for G Web. I was able to do that pretty trivially in the current form. Once this interface layer is added that will considerably more difficult to replicate. I don't know that that's a valid/real "concern" for moving forward, but I figured it was worth mentioning as at least a "minor consideration"

[jimkring]

@jyoung8711

One minor consideration I'll add... At one point, I did a conversion of this library for G Web. I was able to do that pretty trivially in the current form. Once this interface layer is added that will considerably more difficult to replicate. I don't know that that's a valid/real "concern" for moving forward, but I figured it was worth mentioning as at least a "minor consideration"

Hopefully we can stick to "current gen" LabVIEW for while :)