- What are you doing now?
- What do you expect
- What have you seen done wrong
- What are your key pains
Moderator: Christopher Zimmermann
How do you REST?
I asked the attendees what approach they were using to create a REST endpoint to get their Magnolia content currently:
OOTB Nodes endpoint
Templates (render-type json)
Templates & jsonfn
Custom Java endpoints
|Custom Servlet - straight to JCR.||5||Dynamic scalable endpoint|
|Spring MVC REST - Approch of blossom||1|
Some use cases for the endpoints
- Authors can publish content and create a page purely via a JSON endpoint.
- This was done to have a simpler interface for "light authors", for whom the Magnolia interface is too complicated / error-prone.
- (Or maybe also due to security considerations.)
- Communicating with ansible deployment processes.
- Add new subscribers.
- Status information going into external dashboards (screens on walls)
- Custome servlet for queries and authentication.
- Generating PDF
Endpoints for devops tasks were popular.
Querying is very, very important.
- It should be easy for simple cases,
- it should be possible to complex searches.
- What could the query language be?
Add support to upload a file. (Note this is possible now but could be made easier: https://documentation.magnolia-cms.com/display/DOCS/REST+API#RESTAPI-Creatingassets)
- For example, they want to be able to upload content that users submit with Forms.
- Spring REST is very convenient for this.
People chose to use Servlets for REST because they already knew how to program them. It just seemed the easiest approach.
Consider using query parameters, vs selectors. - Consider how this will effect caching of the requests.
An author should be able to configure an endpoint. (I suppose the idea here is that the author is setting things up in Magnolia - and some frontend developers are consuming it.)
Warning: Be careful when creating JSON (serializing) when you want to expand referenced content - dont go to deep! You might have a huge response if you are not careful.
Conversation about personalization
REST philosophy question: Should the same content always be returned when the url is same? (personaliaztion and authentication)
- No. For example: you should get different responses if you are logged in vs. not logged in.
- What about caching based on these requests?
- Should a url havea "cachable" keyword - or have a timestamp.