Implementation: HTTP Server extension for generic REST interfaces #203
Conversation
f27a7ff to
9998e4d
Compare
ea5787f to
55b37a5
Compare
doc/Changelog.md
Outdated
| * set a response header, including content type. | ||
| * set a custom response payload for all action verbs. | ||
| * return a future and and avoid blocking of the main thread. | ||
| * return an std::future to avoid blocking the main thread. |
doc/Changelog.md
Outdated
| * return an std::future to avoid blocking the main thread. | ||
| * register a single endpoint for collections. | ||
| * filter collections using a query string with a GET request | ||
| * filter collections using a query string with GET requests. |
There was a problem hiding this comment.
Style: no '.' at the end (most items are like that)
| std::promise<T> promise; | ||
| promise.set_value( value ); | ||
| return promise.get_future(); | ||
| } |
There was a problem hiding this comment.
I feel somewhat strongly about not having this as part of the zeroeq API. It does not belong here, but to lunchbox/extra. I hid it on purpose in my CR for that reason, until we figure the above out.
There was a problem hiding this comment.
Yes, it is missing from the standard. It could go to this future Extra project above ZeroEQ at some point, but now I see two solutions:
- make this header private like you had it and let users figure out how to make a ready Response.
- new alternative: keep the header public but change the function to:
std::future<Response> make_ready_response(...);
forwarding the arguments to the Response constructor, as that is the only use case for this helper. I think this would be quite nice to use!
There was a problem hiding this comment.
You can avoid copy :
template < typename T >
std::future make_ready_future(T&& value)
{
std::promise promise;
promise.set_value(std::forward< T >(value));
return promise.get_future();
}
There was a problem hiding this comment.
@kaabimg you're perfectly right, this was an oversight. The new make_ready_response() function will correctly forward the arguments to the Response constructor.
| }; | ||
|
|
||
| /** HTTP codes to be used in a Response. */ | ||
| enum Code |
There was a problem hiding this comment.
I have a last-minute doubt about this. It felt somehow convenient (at least for the Tide unit tests) to have response.code directly comparable with integer values (200, 404) instead of having to use their enum name because many of those codes are well-known. What do you think?
60ab750 to
faba37d
Compare
- simplifications in server.cpp - added missing remove() for all Methods - fix missing or incomplete unit tests
4af00dc to
a6f1cfe
Compare
a6f1cfe to
7b19030
Compare
|
restest this please |
No description provided.