Upload
tobias-wunden
View
77
Download
5
Embed Size (px)
Citation preview
application apia common interface for the ingegration of
external applicationsTobias Wunden Co-Founder, CTO
for the open minded
First name, Last name Position
for the open mindedfor the open minded
01
today’s limitations
architecture for an application api
versioning
authentication & authorization
a closer look at the api itself
some sort of roadmap
First name, Last name Position
for the open mindedfor the open minded
today’s limitations
01a look at the current service api, its
strengths and weaknesses
– for the open minded
existing service api
not versioned, difficult to move forward
optimized for admin ui and service orientation
difficult to restrict based on roles and per resource
not overly performant
First name, Last name Position
for the open mindedfor the open minded
02centralized, distributable and fast
proposed architecture
– for the open minded
Workflows
Scheduling
Archive
2
Application API
3
1
?
Message Bus
4
architecture
Idx
6
5
authz
SSLCertificates
SSLCertificates
auth authnauth
– for the open minded
versioning
support for multiple versions
endpoints to gather available version
default version
– for the open minded
versioning
support for multiple versions
endpoints to gather available version
default version
GET /api/version
{ "versions": [ "v1.0.0", "v1.1.0" ], "default": "v1.1.0" }
– for the open minded
versioning
support for multiple versions
endpoints to gather available version
default version
specified using the accept header
– for the open minded
versioning
support for multiple versions
endpoints to gather available version
default version
specified using the accept header
Accept: application/v1.0.0+json
First name, Last name Position
for the open mindedfor the open minded
authentication & authorization
04roles, users and restrictions
– for the open minded
authentication
api supports whatever spring security supportsbasic authentication, ssl certificates, …
– for the open minded
authorization
what level of access should be provided
we all know login as root is bad
requirement for sudo mode
special roles role_api, role_sudo
user and role switching
– for the open minded
authorization
what level of access should be provided
we all know login as root is bad
requirement for sudo mode
special roles role_api, role_sudo
user and role switching
GET /api/
X-RUN-AS-USER: john.doe X-RUN-WITH-ROLES: ROLE_A,ROLE_B
– for the open minded
authorization
what level of access should be provided
we all know login as root is bad
requirement for sudo mode
special roles role_api, role_sudo
user and role switching
access restriction by roles
– for the open minded
authorization
what level of access should be provided
we all know login as root is bad
requirement for sudo mode
special roles role_api, role_sudo
user and role switching
access restriction by roles
– for the open minded
authorization
what level of access should be provided
we all know login as root is bad
requirement for sudo mode
special roles role_api, role_sudo
user and role switching
access restriction by roles
<sec:intercept-url pattern=“/api/event/*/attachments.json" method="GET" access=“ROLE_UI_EVENTS_DETAILS_ATTACHMENTS_VIEW"/>
<sec:intercept-url pattern=“/api/event/*/attachments.json" method="POST" access=“ROLE_API_EVENTS_DETAILS_ATTACHMENTS_WRITE" />
First name, Last name Position
for the open mindedfor the open minded
05a closer look at the individual resources
individual apis
– for the open minded
individual apis
base api: versioning
events api: the obvious
series api: more obvious stuff
security api: url signing
– for the open minded
roadmap (sort of)
initial version 1.0 implemented “soon” including base, events, series and security api
users and groups specified but not implemented
capture api is the logical next step