[commits] [Wiki] changed: Project/HordeApiRewrite

[Ralf Lang (B1 Systems GmbH)]

rlang  Sun, 01 Apr 2018 20:56:48 +0000

Modified page: https://wiki.horde.org/Project/HordeApiRewrite
New Revision:  3
Change log:  Consider some RPCs

@@ -167,8 +167,61 @@

  App Level:
  Upstream provides defaults on which RPC methods are available and  
how they are protected (multiple available).
  Admin / Config may override, empty config uses defaults
+
+++ API characteristics
+
+LOCAL: INTERNAL
+
+- use registry to discover API methods and their implementations
+- any api/method combination may be served by any application  
(registry knows)
+- no real metadata on parameter count and formats available
+- currently no named parameters
+- can directly use objects as parameters or return types (rarely used  
yet, breaks external apis as of now)
+
+RPC: JSON-RPC, XML-RPC
+
+- use registry to discover API methods and their implementations
+- wraps INTERNAL API in specific formats (JSON, XML)
+- Currently breaks for INTERNAL apis which use objects
+- Requires authentication, but any authorization/limits beyond that  
is left to the INTERNAL method implementation
+- Needs custom serialization for API objects which don't implement __toString
+- In theory, named parameters are possible, but the Horde  
infrastructure can't handle them
+- HTTP-wise, it's POST to a well-known endpoint
+- need to parse data to find the appropriate api/method, hence implementation
+
+
+Webdav, Caldav, Carddav:
+- Fixed set of methods
+- Webdav implemented for multiple resources, Caldav/Carddav backends  
are really designed to work for one app each
+- No need to discover or route methods, can use fixed class layout  
for implementation (browse, delete, ...)
+
+REST:
+- Resource-centric
+- Should we assume each registry API is a resource?
+- Any URL formats and lengths possible,
+- methods per resource should be limited to http verbs
+- multiple input and output formats may be governed by content type
+- Supports multiple API versions in parallel (either by URL or by  
content type)
+- each request must be authenticated, no sessions.
+
+Horde AJAX Framework
+- Not currently part of the RPC family
+- separate endpoint
+- URL exposes application and method
+- Uses cookies/sessions/tokens
+- mostly JSON
+
+
+SOAP:
+- Unsure if it really still works
+- similar to XML-RPC
+- but SHOULD generate meta information for the client (where? how?)
+
+Common:
+- We can discern each http remote protocol by URL and/or content  
type. What is not covered, should be assumed REST.
+- Once we know the protocol, we know how to find out API and method  
(and, via registry, implementation)

  ++ Resources