-
Notifications
You must be signed in to change notification settings - Fork 18
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
HTTP Client Plugin Interface #35
Comments
@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. |
@jimkring Agreed! |
@jyoung8711 This user story is based on your feedback. Please LMK if you’d add or change anything. Thx! |
@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" |
Hopefully we can stick to "current gen" LabVIEW for while :) |
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
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
http-client
implementation is used by the REST Client, to create their own components that accept an http-client plugin.Additional Outcomes
Next Steps
main
intodevelop
(so we can start making PRs intodevelop
) #36http-request
,http-response
,http-headers
#37docs
that describe how to create a plug-in (and plug-in architecture overview) #38tests
that verify functionality of the REST Client and the various http-client plug-ins #39ni-advanced-http-client
#40dot-net-http-client
#41The text was updated successfully, but these errors were encountered: