Difference between revisions of "2014-02-12 Telephone Conference DEVROOM / stepping stone GmbH"
From stoney cloud
[unchecked revision] | [unchecked revision] |
(→Transcript of the Telephone Conference between DEVROOM / stepping stone GmbH) |
(→Transcript) |
||
(13 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 57: | Line 57: | ||
| width="40px" | 1 | | width="40px" | 1 | ||
− | | width="800px" | No location attribute used. | + | | 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" | Info | ||
| width="70px" | All | | width="70px" | All | ||
Line 63: | Line 63: | ||
|- | |- | ||
− | + | | width="40px" | 2 | |
− | | width="40px" | | + | | 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" | | + | |
| width="70px" | Info | | width="70px" | Info | ||
| width="70px" | All | | width="70px" | All | ||
Line 71: | Line 70: | ||
|- | |- | ||
− | | width="40px" | | + | | width="40px" | 3 |
− | | width="800px" | | + | | 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" | Info | ||
| width="70px" | All | | width="70px" | All | ||
Line 78: | Line 83: | ||
|- | |- | ||
− | | width="40px" | | + | | 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 85: | Line 90: | ||
|- | |- | ||
− | | width="40px" | | + | | 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" | | + | <pre> |
− | | width="70px" | | + | ldapsearch -v -H "ldaps://ldapm.stoney-cloud.org" \ |
− | | width="70px" | 2014-02- | + | -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 |
|
Non participants |
|
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:
|
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.
See Mandatory headers for example. The implementation details will be described on another page. |
To Do | MEI / TMU | 2014-02-19 |