• 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)

• 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

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?
• 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.
• 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.
• 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.

• "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:

• 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.