Posted on 08/04/2021 16:32:13
The cart in 'regular' Dynamicweb is kept alive for a user given either a session, a cookie or a userid (and the the user id comes from a user login that is persisted in session)
Now - the webapi is stateless. It has no cookies, hence no sessions. So trying to fetch a page, using the pagview endpoint, and on that page have a paragraph with the cart module will result in an empty cart no matter what - because no user, no cookie or no session exists. So the page will see the cart as empty and do a redirect if it is setup to that, resulting in a 404.
In the context of the webapi, you can consider Rapido as a customisation. It has templates that renders stuff - in those templates there are all sorts of assumptions, i.e. there is a user or a cart, and since we have no sesssion and cookies, the templates will likely run into all kinds of errors due to this.
So - the webapi is not very suitable for getting a pageview where you use a regular page with rendering using templates. It will simply not work very well. Because part of the returning data will be rendered markup from templates that does not comply.
The Pageview in Dynamicweb is to be considered as the 'head' of Dynamicweb. Moving to the 'headless' version, using the webapi, using the pageview to partially render markup makes no sense.
What you will get from the pageview endpoint, when used in a headless-ish setup of your website structure, using items, is a page, its properties, its item data and its paragraphs. Right now those paragraphs comes as markup. In a very near future they will come as a collection of ParagraphViewModels using paragraph and item properties - like if you query them from the paragraphs endpoint.
Some paragraphs will have modules. Those modules comes in 2 flavors - those exposing the good old template tags and those exposing viewmodels. Those exposing viewmodels will at some point also be attached to the paragraph when we have the infrastructure for it (and the paragraphs is coming from the collection of paragraphs on a pageview).
The way of thinking an implementation in a headless environment using the webapis have to change some what compared to using pages with paragrapsh and modules as you do today.
Here is a number of things to consider and how they play out in the 2 environments
| |
Using Dynamicweb and templates |
Using the Webapi in a headless environment |
| Login |
Using a login form, a user logs in and Dynamicweb will send back a cookie and keep a session a live for some time. Whenever a new page is accessed, we find the user from session using the cookie as backup and ensures we have a user context. To get prices etc. |
Using a login form, the username and password is sent to the users endpoint to authenticate the user. A jwt token is returned as the response. The client has to store that token somehow - in a variable in the SPA, using cookies or localdb. At every subsequent request to the web api, the token is send in the auth header and the endpoint will then authorize based on that token. The token will expire and has to be renewed or the user will have to login again. |
| Cart |
When doing ?cartcmd=add Dynamicweb will, using the session, a cookie or the logged in user, find the appropiate cart or create one if missing. Then add the product as an orderline. On subsequent requests to pages, Dynamicweb will remember that and find the cart for displaying and additional cart actions |
Using the webapi, with no states, the client has to keep track of things. So to create a cart, the cart endpoint is called to explicitly create a cart. A cart token is returned and has to be stored in the client like with user above. On subsequent requests to the cart endpoint for adding and changing the cart, that cart token has to be passed along so the endpoint can find the appropiate cart. |
| Product catalog |
Using a page with a paragaph, the product catalog app is added and configured using the UI with how many products to show, where from etc. When that page is rendered, Dynamicweb will use those settings to find the right products, use the userid to find the right price, use the website context to locate the currency, delivery country, if prices are with vat and other funny stuff kept in the context (sesssion/cookie). All of this is rendered using a template setup on the app. |
Using the webapi, the product catalog has its own endpoint where products can be queried and a product listviewmodel is returned. There is no page and no paragraph. Also there is no settings coming from the app installed on the paragraph and there is no context of currency, user and other things. So those settings is send as part of the request. A groupid, a search string, what fields to return, what currency to use, what user (using the bearer token), if prices are with or without vat etc. The endpoint will return just raw data that needs to be rendered in the client |
| Forms |
Add forms to a paragraph, give it settings and a template will render the form. Submitting the form will take care of things and redirect to receipt |
We do not have this endpoint yet, but when it is, it will return a form object with fields and options, and that form has to be rendered in the client. The result of the form can be posted to the upcoming forms endpoint which will take care of things. The receipt has to be showed in the client and handled by the app it self. |
BR Nicolai
