Hi folks,
I'm trying to use the HTTP APIs documented in https://beaker-project.org/docs-release-19/server-api/http.html as follows:
curl --negotiate -H 'Accept: application/json' https://<Beaker server domain>
I have a valid Kerberos ticket, but the main page just returns the HTML list of systems, while the subcollections for available, free and my systems return a login page redirect.
So it appears either something is broken or the API documentation has omitted a required setup step.
Cheers, Nick.
Excerpts from Nick Coghlan's message of 2015-02-19 12:46 +10:00:
Hi folks,
I'm trying to use the HTTP APIs documented in https://beaker-project.org/docs-release-19/server-api/http.html as follows:
curl --negotiate -H 'Accept: application/json' https://<Beaker server domain>
I have a valid Kerberos ticket, but the main page just returns the HTML list of systems, while the subcollections for available, free and my systems return a login page redirect.
So it appears either something is broken or the API documentation has omitted a required setup step.
The endpoints for listing systems (/, /available/, /free/, /mine/) don't actually offer JSON at all right now. Only Atom or the human-readable HTML with grid.
The docs are a bit confusing on this point since they mention "pageable JSON collections" at the very top and then right below it describes the system listing endpoints. But those are not "pageable JSON collections". The only two resources that are pageable JSON collections in 19 are /systems/<fqdn>/activity/ and /systems/<fqdn>/commands/. As we add new Flask-based APIs they will be consistent.
But the system listing endpoints are much, much older (Beaker 0.6) and are using the old TG @paginate stuff which is why they are not consistent with any of the newer APIs. We could probably make the docs call out this inconsistency more explicitly.
I would like to build new endpoints for listing systems that are consistent with everything else, and then make the old ones a deprecated compatibility layer for the new ones. The challenge is the existing very large pile of code for system searching.
In the meantime, parsing Atom to get a list of systems is quite easy. The bkr list-systems subcommand does it, in these 5 lines:
response = session.get(feed_url, stream=True) response.raise_for_status() atom = lxml.etree.parse(response.raw) titles = atom.xpath('/atom:feed/atom:entry/atom:title', namespaces={'atom': 'http://www.w3.org/2005/Atom%27%7D)
https://git.beaker-project.org/cgit/beaker/tree/Client/src/bkr/client/comman...
From: "Dan Callaghan" dcallagh@redhat.com To: "beaker-devel" beaker-devel@lists.fedorahosted.org Sent: Thursday, 19 February, 2015 2:02:31 PM Subject: Re: [Beaker-devel] Receiving HTML rather than JSON despite Accept header
Excerpts from Nick Coghlan's message of 2015-02-19 12:46 +10:00:
Hi folks,
I'm trying to use the HTTP APIs documented in https://beaker-project.org/docs-release-19/server-api/http.html as follows:
curl --negotiate -H 'Accept: application/json' https://<Beaker server domain>
I have a valid Kerberos ticket, but the main page just returns the HTML list of systems, while the subcollections for available, free and my systems return a login page redirect.
So it appears either something is broken or the API documentation has omitted a required setup step.
The endpoints for listing systems (/, /available/, /free/, /mine/) don't actually offer JSON at all right now. Only Atom or the human-readable HTML with grid.
The docs are a bit confusing on this point since they mention "pageable JSON collections" at the very top and then right below it describes the system listing endpoints. But those are not "pageable JSON collections". The only two resources that are pageable JSON collections in 19 are /systems/<fqdn>/activity/ and /systems/<fqdn>/commands/. As we add new Flask-based APIs they will be consistent.
But the system listing endpoints are much, much older (Beaker 0.6) and are using the old TG @paginate stuff which is why they are not consistent with any of the newer APIs. We could probably make the docs call out this inconsistency more explicitly.
Indeed, that was exactly my point of confusion - I forgot that those APIs were currently still HTML & XML only, as the intro section talked specifically about the design of the new APIs rather than the legacy ones.
I got the main listing to work with the following:
curl --negotiate 'https://<server>?tg_format=atom&list_tgp_limit=0'
And figured out this sed hack to extract just the host names:
curl -s --negotiate 'https://<server>?tg_format=atom&list_tgp_limit=0' | sed -n 's_.*<id>.*/view/(.*)</id>.*_\1_p'
However, the qualified listings still came back as a login redirect rather than giving me any data, even with a valid Kerberos ticket and passing --negotiate to curl.
Cheers, Nick.
Excerpts from Nick Coghlan's message of 2015-02-19 14:26 +10:00:
However, the qualified listings still came back as a login redirect rather than giving me any data, even with a valid Kerberos ticket and passing --negotiate to curl.
Yes, sigh... The API does not actually use standard HTTP authentication. We can thank Kobo (and, indirectly, the limitations of xmlrpclib) for that one.
Authentication is described here:
https://beaker-project.org/docs/server-api/xmlrpc.html#authentication
and RFE for accepting standard HTTP authentication:
https://bugzilla.redhat.com/show_bug.cgi?id=1124139
although it's not straigh-forward due to compatibility with the existing /login redirect and form-based auth we have for the web UI.
From: "Dan Callaghan" dcallagh@redhat.com To: "beaker-devel" beaker-devel@lists.fedorahosted.org Sent: Thursday, 19 February, 2015 2:47:55 PM Subject: Re: [Beaker-devel] Receiving HTML rather than JSON despite Accept header
Excerpts from Nick Coghlan's message of 2015-02-19 14:26 +10:00:
However, the qualified listings still came back as a login redirect rather than giving me any data, even with a valid Kerberos ticket and passing --negotiate to curl.
Yes, sigh... The API does not actually use standard HTTP authentication. We can thank Kobo (and, indirectly, the limitations of xmlrpclib) for that one.
Authentication is described here:
https://beaker-project.org/docs/server-api/xmlrpc.html#authentication
and RFE for accepting standard HTTP authentication:
https://bugzilla.redhat.com/show_bug.cgi?id=1124139
although it's not straigh-forward due to compatibility with the existing /login redirect and form-based auth we have for the web UI.
I'm a fan of just adding a new dedicated JSON API endpoint that used standard auth, in order to bypass the tricky compatibility issues associated with trying to do the enhancement in place.
I know you think that's a horrible hack when it should be possible to do it through content negotiation without introducing new URLs, but the much simpler compatibility story may make it worth it.
I'm also still keen to look at using http://www.flaskapi.org/ to improve API discoverability, and that necessarily involves having the "browsable REST API" and the main UI (including the "single page applications" like the system page) anchored at different endpoints.
Cheers, Nick.
beaker-devel@lists.fedorahosted.org