[kea-dev] GSoC 2019 with ISC and Kea
godfryd at isc.org
Thu Mar 7 05:33:43 UTC 2019
Regarding updating HTTP API it would be good to consider implementing real REST API
that behaves according to theory (current approach seams rather like RPC).
Here is some reference about REST: https://en.wikipedia.org/wiki/Representational_state_transfer.
So this way we are compliant with RESTfulness and at the same time exposing read-only endpoints via HTTP GET.
----- Original Message -----
From: "Tomek Mrugalski" <tomasz at isc.org>
To: kea-dev at lists.isc.org
Sent: Wednesday, March 6, 2019 8:54:18 PM
Subject: Re: [kea-dev] GSoC 2019 with ISC and Kea
On 03.03.2019 13:08, James Wang wrote:
> Hello Kea Developers,
> I am James Wang, a computer science student from The Chinese University
> of Hong Kong, Shenzhen.
And welcome to the Kea project.
> I am interested in network internals and network security (because of
> China's Internet Censorship) before I choose to study computer science.
> In all GSoC organizations, ISC is the few ones that are related to
> network internals, and the Kea project offers ideas that I believe I can
> tackle in 3 months' time. Therefore, I want to participate in GSoC 2019
> with ISC and the Kea project.
> I would like to tackle Idea No.3 HTTP GET Support. Although No.6 LDAP
Great to hear!
> backend and No.8 leasequery support also sound attractive to me, I think
> I have the highest chance of success in Idea No.3, because I have past
> experience in socket programming, web backend development and HTTP protocol.
Out of those three, HTTP GET is by far the most frequently requested
one. There are some cases where leasequery could help, but it's not that
popular. As for LDAP, there's only one network operator that was
explicitly asking for it. It's a large scale DHCP deployment, though.
> Here's my draft plan. If my project succeeded, all builtin read-only
> APIs in Kea Control Agent would have a GET endpoint. In addition, Kea
> would have a health endpoint API (Issue #318
> 1. Find all read-only APIs and map each one to a GET endpoint
> 2. Add a GET request parser to the HTTP server, if there is none
There is none. One way to approach this would be to look at the POST
request parser first and see how the code could be augmented to handle
POST and GET requests separately.
> 3. Serve GET request by converting them into their equivalent POST requests
> 4. Write documentations on all GET endpoints and how to configure
> reverse proxy servers (apache2, nginx) to GET-only
> 5. Implement health endpoint API with both GET and POST support (Issue
> #318 <https://gitlab.isc.org/isc-projects/kea/issues/318>)
> 6. I believe we should keep the existing POST methods, for backward
> compatibility and consistent APIs. New read-only APIs should also
> support POST methods
> 7. If time and my ability permit, add a way for hook libraries to
> define their own GET endpoint
That sounds like a very good plan.
There's also a question whether each command can be called using both
POST and GET, POST only, GET only or neither. There are use cases for
each of those. Some people would want to to use both for convenience.
POST only make sense for commands that alter configuration or state, GET
only for read-only operations and neither in case sysadmin wants to
disable some commands. There's also a question of letting people
transition from earlier Kea versions where everything was running on
POST. We'll need to think about some sort of a mechanism to govern what
type of requests are possible.
> I have successfully built and installed Kea (1.5.0-git) with unit tests
> and MySQL support on a Ubuntu VM. My build passed the unit tests ("make
> check"). I tested the build's DHCPv4 server with a Windows XP VM and a
> Windows 7 VM. Both clients were assigned a valid IP address and could
> access the NAT network and Internet. My Windows 10 host was also
> assigned a valid IP address. Now I'm reading the source code and
> documentations, trying to understand the implementation of the HTTP
> server and Kea Control Agent.
That is most impressive. We had many students being interested in Kea
last year, but none of them managed to do so much and propose so
excellent initial proposal.
> I would appreciate any suggestions and tips. Thanks for your time.
Thank you for your interest in Kea. I look forward to see you in the Kea
I'll have some other comments for you sent off-line soon.
kea-dev mailing list
kea-dev at lists.isc.org
More information about the kea-dev