05-18-2020, 07:38 PM
Heya,
I'm creating an app with a front-end Javascript framework that connects to a TACTIC back-end.
I want to use the TACTIC REST interface instead of embedding client_api.js, xmlrpc.js etc.
Once I have a ticket set as cookie, I'm able to make REST API calls using fetch:
url = 'http://xxxx.com/tactic/fitnessmedia/REST?method=eval&args=["@SOBJECT(fitnessmedia/class)"]'
fetch(url, {'method': 'POST'}).then(resp => resp.json()).then(data => console.log(data))
This fetch call uses the login_ticket cookie.
If I don't have a ticket, I'm trying to do a login through REST.
- Should I replicate the WebLoginWdg? It appears that on load, it sets a login_ticket cookie, and then after login, sets a new login_ticket cookie.
- I tried to do a REST get_ticket call, but that receives an error that I haven't delved into.
- I've already made a public guest REST endpoint, and I can add a getTicket call to this.
I want to know if this is something we want to support through the REST interface, and what the best practice should be.
Thanks!
Celton
I'm creating an app with a front-end Javascript framework that connects to a TACTIC back-end.
I want to use the TACTIC REST interface instead of embedding client_api.js, xmlrpc.js etc.
Once I have a ticket set as cookie, I'm able to make REST API calls using fetch:
url = 'http://xxxx.com/tactic/fitnessmedia/REST?method=eval&args=["@SOBJECT(fitnessmedia/class)"]'
fetch(url, {'method': 'POST'}).then(resp => resp.json()).then(data => console.log(data))
This fetch call uses the login_ticket cookie.
If I don't have a ticket, I'm trying to do a login through REST.
- Should I replicate the WebLoginWdg? It appears that on load, it sets a login_ticket cookie, and then after login, sets a new login_ticket cookie.
- I tried to do a REST get_ticket call, but that receives an error that I haven't delved into.
- I've already made a public guest REST endpoint, and I can add a getTicket call to this.
I want to know if this is something we want to support through the REST interface, and what the best practice should be.
Thanks!
Celton