Difference between revisions of "2014-02-12 Telephone Conference DEVROOM / stepping stone GmbH"

From stoney cloud
Jump to: navigation, search
[unchecked revision][unchecked revision]
(→‎Transcript)
(→‎Transcript)
 
(7 intermediate revisions by the same user not shown)
Line 34: Line 34:
 
| width="800px"  |  
 
| width="800px"  |  
 
Open Questions:
 
Open Questions:
−
* "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?
+
* (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?
−
* 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.
+
* (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?
 
* 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.
 
** Documetation fixed.
−
* 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?
+
* (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?
−
* [[stoney_core:_REST_API#Relations]]: Ich würde in der jetzigen Implementierung die Relationen gerne weglassen.
+
* (4) [[stoney_core:_REST_API#Relations]]: Ich würde in der jetzigen Implementierung die Relationen gerne weglassen.
−
* 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.
+
* (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.
  
 
|-  
 
|-  
Line 63: Line 63:
 
|-
 
|-
  
−
 
+
| width="40px"  | 2
−
| width="40px"  | 1
+
| width="800px"  | q and sort are [[stoney_core:_REST_API#Reserved_Keywords | Reserved Keywords]] and are therefore not allowed in the JSON payload.
−
| width="800px"  | q and sort are GET parameters and have got nothing to do with the JSON payload. Therefore we don't see a current of future issue.
+
 
| width="70px"  | Info
 
| width="70px"  | Info
 
| width="70px"  | All
 
| width="70px"  | All
Line 71: Line 70:
 
|-
 
|-
  
−
| width="40px"  | 1
+
| width="40px"  | 3
 
| width="800px"  | The REST API defines the following line as a return value. This is required and will not change.
 
| 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"
 
* "location": "https://api.example.com/v1/resellers/4000001/customers"
Line 84: Line 83:
 
|-
 
|-
  
−
| width="40px"  | 1
+
| 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="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"  | Info
Line 91: Line 90:
 
|-
 
|-
  
−
| width="40px"  | 1
+
| width="40px"  | 5
−
| width="800px"  | Yes, you have this possibility. We'll send you an example how to do this.
+
| width="800px"  | No, currently you do not have this possibility. The following example will return all the entries and display the modifyTimestamp:
−
* Additionally we'll define how to create the hash used as the ETag.
+
<pre>
−
** Use Case 1: Business object has a one to one relation in the LDAP directory.
+
ldapsearch -v -H "ldaps://ldapm.stoney-cloud.org" \
−
** Use Case 2: Business object has a one to N relation in the LDAP directory.
+
              -b "ou=people,dc=stoney-cloud,dc=org" \
−
| width="70px"  | Info
+
              -D "cn=Manager,dc=stoney-cloud,dc=org" \
−
| width="70px"  | All
+
              -s one "(objectClass=*)" \
−
| width="70px"  | 2014-02-12
+
              "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
 
|-
 
|-
  

Latest revision as of 16:29, 12 February 2014

Transcript of the Telephone Conference between DEVROOM / stepping stone GmbH

Location Skype
Date Wednesday, the 12th of Feburary 2014
Time 11:30 until 12:00
Participants
  • Christian Wittkowski <christian.wittkowski@devroom.de>: CWI
  • Christian Affolter <christian.affolter@stepping-stone.ch>: CAF
  • Tiziano Müller <tiziano.mueller@stepping-stone.ch>: TMU
  • Michael Eichenberger <michael.eichenberger@stepping-stone.ch>: MEI (Transcript)
Non participants
  • Pat Kläy <pat.klaey@stepping-stone.ch>: PKL
  • David Vollmer <david.vollmer@stepping-stone.ch>: DVO
  • Pascal Jufer <pascal.jufer@stepping-stone.ch>: PJU
Agenda

Open Questions:

Transcript

No. Text What? Who? When?
1 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. Info All 2014-02-12
2 q and sort are Reserved Keywords and are therefore not allowed in the JSON payload. Info All 2014-02-12
3 The REST API defines the following line as a return value. This is required and will not change.

You are correct in the assumption, that the following line will return the same information:

Additional Information:

  • 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.
Info All 2014-02-12
4 We've updated the Relations section of the documentation. It should be simpler to implement this way. Info All 2014-02-12
5 No, currently you do not have this possibility. The following example will return all the entries and display the modifyTimestamp: 
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

To achieve server side sorting, we need to install the Server Side Sorting and Virtual List View Overlay:

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 Mandatory headers for example. The implementation details will be described on another page.

To Do MEI / TMU 2014-02-19
Retrieved from "http://wiki.stoney-cloud.org/mediawiki/index.php?title=2014-02-12_Telephone_Conference_DEVROOM_/_stepping_stone_GmbH&oldid=3115"