| width="800px" |
* Pat Kläy <pat.klaey@stepping-stone.ch>: PKL
* Christoph Scheurer <christoph.scheurer@stepping-stone.ch>: CSC
* David Vollmer <david.vollmer@stepping-stone.ch>: DVO
* Pascal Jufer <pascal.jufer@stepping-stone.ch>: PJU
| width="800px" |
Open Questions:
* (1) "location" JSON attribute: Der Name kann ein Problem sein wenn das Business Object ein Attribute gleichen Namens. Vielleicht können wir das rest_location nennen?* (2) URL Parameter "sort" und "q" ([[stoney_core:_REST_API#Filtering.2C_sorting_and_searching]]): Hier könnte ebenfalls der Parametername ein Problem werden wenn das Business Object ein Attribute gleichen Namens besitzt.
* Im Bereich [[stoney_core:_Resellers_Resource_-_REST_API#Reseller_element_retrieval_response_message_body]] sind die drei Parameter customers, employees und users im Beispiel alle mit dem Namen "location" gesetzt. Müssten die nicht z.B.: "customers": "https://....." heissen?
** Documetation fixed.
* (3) Gleicher Bereich: In der Zeile "location": "https://api.example.com/v1/resellers/4000001/customers" könnte die URL auch so geschrieben werden: https://api.example.com/v1/customers?belongsToResellerUID=4000001 Hier meine ich braucht es diese Relation Variante nicht?* (4) [[stoney_core:_REST_API#Relations]]: Ich würde in der jetzigen Implementierung die Relationen gerne weglassen.* (5) Gibt es in der LDAP Suche eine Möglichkeit sich in einem Knoten nur den Eintrag geben zu lassen mit dem jüngsten modifyTimestamp? Dies wäre für die Ermittlung des <code>[http://en.wikipedia.org/wiki/HTTP_ETag ETag ]</code> bzw. Last-Modified wichtig.
|-
| width="40px" | 1
| width="800px" | In principal, the REST API should know the scope of variables. For example: billingAddress should be able to contain location. No location attribute is currently used, but it could be used in the future.
| width="70px" | Info
| width="70px" | All
|-
| width="40px" | 2
| width="800px" | q and sort are [[stoney_core:_REST_API#Reserved_Keywords | Reserved Keywords]] and are therefore not allowed in the JSON payload.
| width="70px" | Info
| width="70px" | All
| width="70px" | 2014-02-12
|-
| width="40px" | 3
| width="800px" | The REST API defines the following line as a return value. This is required and will not change.
* "location": "https://api.example.com/v1/resellers/4000001/customers"
You are correct in the assumption, that the following line will return the same information:
* https://api.example.com/v1/customers?belongsToResellerUID=4000001
Additional Information:
* [[stoney_core:_REST_API#Filtering.2C_sorting_and_searching | Filtering, sorting and searching]] allows for the above query.
* Via proper routing both calls (urls) should end in the same controller without further manual programming, as the framework should be able to do this for you.
| width="70px" | Info
| width="70px" | All
| width="70px" | 2014-02-12
|-
| width="40px" | 4
| width="800px" | We've updated the [[stoney_core:_REST_API#Relations | Relations]] section of the documentation. It should be simpler to implement this way.
| width="70px" | Info
| width="70px" | All
| width="70px" | 2014-02-12
|-
| width="40px" | 5
| width="800px" | No, currently you do not have this possibility. The following example will return all the entries and display the modifyTimestamp:
<pre>
ldapsearch -v -H "ldaps://ldapm.stoney-cloud.org" \
-b "ou=people,dc=stoney-cloud,dc=org" \
-D "cn=Manager,dc=stoney-cloud,dc=org" \
-s one "(objectClass=*)" \
"modifyTimestamp" \
-LLL -W
filter: (objectClass=*)
requesting: modifyTimestamp
dn: uid=4000002,ou=people,dc=stoney-cloud,dc=org
modifyTimestamp: 20131220135513Z
</pre>
To achieve server side sorting, we need to install the Server Side Sorting and Virtual List View Overlay:
* Internet-Draft: [http://www.ietf.org/proceedings/55/I-D/draft-ietf-ldapext-ldapv3-vlv-09.txt draft-ietf-ldapext-ldapv3-vlv-09.txt]
* OpenLDAP Overlay: [http://www.openldap.org/software/man.cgi?query=slapo-sssvlv&apropos=0&sektion=0&manpath=OpenLDAP+2.4-Release&format=html slapo-sssvlv] - Server Side Sorting and Virtual List View overlay to slapd.
How to set a LDAP control: http://search.cpan.org/~marschap/perl-ldap-0.58/
We'll define how to create the hash used as the ETag.
* Use Case 1: Business object has a one to one relation in the LDAP directory.
* Use Case 2: Business object has a one to N relation in the LDAP directory.
See [[stoney_core:_REST_API#Mandatory_headers | Mandatory headers]] for example. The implementation details will be described on another page.
| width="70px" | To Do
| width="70px" | MEI / TMU
| width="70px" | 2014-02-19
|-
|}
[[Category:2014]]