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)
 
(11 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 ETag 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"
 
You are correct in the assumption, that the following line will return the same information:
 
You are correct in the assumption, that the following line will return the same information:
 
* https://api.example.com/v1/customers?belongsToResellerUID=4000001
 
* https://api.example.com/v1/customers?belongsToResellerUID=4000001
−
[[stoney_core:_REST_API#Filtering.2C_sorting_and_searching | Filtering, sorting and searching]] allows for the above query.
+
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"  | Info
 
| width="70px"  | All
 
| width="70px"  | All
Line 83: Line 83:
 
|-
 
|-
  
−
| width="40px"  | 1
+
| width="40px"  | 4
−
| width="800px"  |  
+
| 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
 
| width="70px"  | All
 
| width="70px"  | All
Line 90: Line 90:
 
|-
 
|-
  
−
| width="40px"  | 1
+
| width="40px"  | 5
−
| width="800px"  |  
+
| width="800px"  | No, currently you do not have this possibility. The following example will return all the entries and display the modifyTimestamp:
−
| width="70px"  | Info
+
<pre>
−
| width="70px"  | All
+
ldapsearch -v -H "ldaps://ldapm.stoney-cloud.org" \
−
| width="70px"  | 2014-02-12
+
              -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
 
|-
 
|-
  

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"