-
Notifications
You must be signed in to change notification settings - Fork 449
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 API #309
Http Client API #309
Conversation
Codecov Report
@@ Coverage Diff @@
## master #309 +/- ##
==========================================
+ Coverage 94.55% 94.56% +0.01%
==========================================
Files 146 146
Lines 6610 6629 +19
==========================================
+ Hits 6250 6269 +19
Misses 360 360
|
Have raised request for this. |
virtual void set(nostd::string_view const &name, nostd::string_view const &value) = 0; | ||
|
||
// Inserts a name/value pair | ||
virtual void add(nostd::string_view const &name, nostd::string_view const &value) = 0; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What's the exact difference between add
and set
? Will add
allow having multiple values for a single header? Will set
fail if an element with the given name
doesn't yet exist?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we should refactor this. Original idea was that:
add
- appends to multimap.set
- either adds or replaces if header already exists.
Maybe we should converge on alternate names for that.
I'm not sure if we really want to employ nostd::string_view
here though. It's in SDK, which won't have ABI-stability requirement..... Unless we want to runtime dynamically inject an instance of HTTP stack.
// Returns: | ||
// If there are multiple headers with same name, it returns any one of the value | ||
// (implementation defined) Empty string if there is no header with speicfied name.. | ||
virtual nostd::string_view const &get(nostd::string_view const &name) const = 0; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We usually don't pass string_view
s as reference in other parts of the API.
// must be set by the caller. The request object can then be sent | ||
// using SendRequestAsync(). If you are not going to use the request object | ||
// then you can delete it safely using its virtual destructor. | ||
virtual HttpRequest *CreateRequest() = 0; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we return a std::unique_ptr
here?
// latter case, the OnHttpResponse() callback is called before this | ||
// method returns. You must keep the callback object alive until its | ||
// OnHttpResponse() callback is called. | ||
virtual void SendRequest(HttpRequest *request, HttpResponseCallback *callback) = 0; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Moving the request
as an unique pointer would enforce the conditions you documented above (taking ownership and no modification after the call): std::unique_ptr<HttpRequest>&& request
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
All the raw pointers would be converted to shared_ptr/unique_ptr in new PR. In this case, I don't see need to move semantics as <unique_ptr> would anyway transfer the ownership.
{ | ||
public: | ||
// Inserts a name/value pair, and removes elements with the same name. | ||
virtual void set(nostd::string_view const &name, nostd::string_view const &value) = 0; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why are the method names lower case here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Will fix this.
enum class HttpResult : uint8_t | ||
{ | ||
// Response has been received successfully from target server. | ||
HttpResult_OK = 0, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please conform the the Google C++ Style Guide. Here's the part for enums.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Will fix this.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd like to block merging this until we sort out some (minor) legal Q 😄 ... We can continue iterations / discussions on this.
[](const std::string &s1, const std::string &s2) -> bool { | ||
std::string str1(s1.length(), ' '); | ||
std::string str2(s2.length(), ' '); | ||
auto lowerCase = [](char c) -> char { return tolower(c); }; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Missing std::
before tolower(c);
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We may want to use this implementation into some form of header-only common utility class, since the same pattern is being used more than once elsewhere.
|
||
// HttpHeaders implementation | ||
class HttpHeaders : http_api::HttpHeaders, | ||
std::multimap<std::string, std::string, decltype(CaseInsensitiveComparator)> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should this std::multimap
based on nostd::string_view
according to insert()
called in add()
below?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd actually advocate again that we can just use std::string
here in SDK for the sake of simplicity and compat with older compilers, just using plain standard C++11 (or maybe C++14) classes, so that external components do not have to take a dependency on nostd
. There is no ABI stability guarantee for exporters. We discussed it in prior SIG meetings that we are not providing ABI stable interface in SDK, for exporters, and thus, using nostd
here is a bit of an overkill.
In short: there is no requirement to use nostd
inside the SDK, because there is no ABI-stability requirement/guarantee within the SDK code.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We definitely shouldn't store nostd::string_view
in the multimap
.
There are some slight advantages of using nostd::string_view
over std::string
as type for parameters in function calls, as this allows users to pass both std::string
and const char*
without creating an intermediate std::string
. But I don't have a strong preference for it in this API, which will not be on a performance critical path.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This would be changed in new PR. string_view
class won't be used anymore. Although agree on string_view
advantage as stated by @pyohannes
}; | ||
|
||
// The HttpHeaders class contains a set of HTTP headers. | ||
class HttpHeaders |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is there a place where do use HttpHeaders
in API? Does it mean we need to have a transform somewhere from std::multimap<std::string, std::string>
used within the SDK - to ABI-safe HttpHeaders
implementation used in API surface? Can you provide some concrete example where we require this in API?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't see a use case for this in the API.
@maxgolov @reyang @pyohannes @ThomsonTan Thank you all for the review comments. I would abandon this PR due to the current non-clarity of the copyright issue as some part is coming from Microsoft's MIT licensed code base. I am in process of re-writing the API and would be raising the new PR in couple of days. I would be respond to relevant comments ( which holds good in new PR too) in this PR before abandon. |
Should these headers be in the SDK rather than the API? IMO the API is just for instrumentation calls and the no-op default implementation thereof. |
@g-easy Yes, that's the plan for new PR. Would be moving both interface / implementation to SDK. |
Closing for copyright issues, new PR raised : #370 |
This PR brings the HTTP client API to be used across various exporters ( eg zipkin, azure monitor ) to communicate with remove telemetry servers.
TBD: