Difference between revisions of "2014-02-12 Telephone Conference DEVROOM / stepping stone GmbH"
From stoney cloud
[unchecked revision] | [unchecked revision] |
(→Transcript) |
|||
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. | + | * (3) [[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. | + | * (4) 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" | | + | |
| 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="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 | ||
Line 71: | Line 70: | ||
|- | |- | ||
− | | width="40px" | | + | | 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" | | + | | width="40px" | 3 |
| 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" | | + | | width="40px" | 4 |
| width="800px" | Yes, you have this possibility. We'll send you an example how to do this. | | width="800px" | Yes, you have this possibility. We'll send you an example how to do this. | ||
* Additionally we'll define how to create the hash used as the ETag. | * Additionally we'll define how to create the hash used as the ETag. |
Revision as of 12:06, 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 GET parameters and have got nothing to do with the JSON payload. Therefore we don't see a current of future issue. | 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 |
3 | We've updated the Relations section of the documentation. It should be simpler to implement this way. | Info | All | 2014-02-12 |
4 | Yes, you have this possibility. We'll send you an example how to do this.
See Mandatory headers for example. The implementation details will be described on another page. |
Info | All | 2014-02-12 |