summaryrefslogtreecommitdiffstats
path: root/BUILD.txt
diff options
context:
space:
mode:
authorPetr Viktorin <pviktori@redhat.com>2012-12-07 10:54:07 -0500
committerMartin Kosek <mkosek@redhat.com>2013-02-21 16:26:09 +0100
commit24bca144a8049cea8683afd699d2e0e158b5f164 (patch)
tree9314443e230d79cb8c7930ce73842036b3b8c054 /BUILD.txt
parent8af5369cba1ff0e6d8baae90f3d93b40e91e85d6 (diff)
downloadfreeipa-24bca144a8049cea8683afd699d2e0e158b5f164.tar.gz
freeipa-24bca144a8049cea8683afd699d2e0e158b5f164.tar.xz
freeipa-24bca144a8049cea8683afd699d2e0e158b5f164.zip
Add client capabilities, enable messages
The API version the client sends can now be used to check what the client expects or is capable of. All version tests IPA does will be be named and listed in one module, ipalib.capabilities, which includes a function to test a specific capability against an API version. Similarly to Python's __future__ module, capabilities.py also serves as documentation of backwards-incompatible changes to the API. The first capability to be defined is "messages". Recent enough clients can accept a list of warnings or other info under the "messages" key in the result dict. If a JSON client does not send the API version, it is assumed this is a testing client (e.g. curl from the command line). Such a client "has" all capabilities, but it will always receive a warning mentioning that forward compatibility is not guaranteed. If a XML client does not send the API version, it is assumed it uses the API version before capabilities were introduced. (This is to keep backwards compatibility with clients containing bug https://fedorahosted.org/freeipa/ticket/3294) Whenever a capability is added, the API version must be incremented. To ensure that, capabilities are written to API.txt and checked by `makeapi --validate`. Design page: http://freeipa.org/page/V3/Messages Ticket: https://fedorahosted.org/freeipa/ticket/2732
Diffstat (limited to 'BUILD.txt')
0 files changed, 0 insertions, 0 deletions