Hi, I just want to ask what is the difference between the 2 keywords?
What is the best practice to be used?
create Session url ${STAGING_URL_API} verify=${True}
${headers}= Create Dictionary Content-Type=application/x-www-form-urlencoded Authorization=${token}
${response}= Post On Session url/${path} ${empty} headers=${headers}
or
${headers}= Create Dictionary Content-Type=application/x-www-form-urlencoded Authorization=${token}
${response}= Post ${STAGING_URL_API}/${path} ${empty} headers=${headers}
not sure why there are 2 POST keywords that’s why i want to know which one is better?
Thanks!
As far as I know the library first used POST and then they renamed it to POST on Session. It is the same keyword and the first one will be removed. Are you not receiving a deprecation error when you use POST?
ohh nice. thank you. I have not actually used the POST keyword. Just want to know if I could still use it since Post on Session is giving me less flexibility as I wanted to directly passed an endpoint without using a create session. And it seems that you cannot single out the create session keyword. But thank you for your response.
From a quick glance, there’s a bit of mixing url with uri and endpoint in the RequestLibrary. The Post On Session keyword takes an url parameter and calls a method internally that takes that url as value for its uri parameter, while that uri is normally referred to as endpoint.
The Create Session takes an url argument that is the base-url, also known as origin.
Now with that in mind, if you have multiple origins, you’ll have to create multiple Sessions. But you could do so in the Suite Setup and just do the minimal; pass an alias and url (origin) to them and go from there.
And if you really want to work around having multiple sessions, it looks like you can actually do so by passing url=${EMPTY} to Create Session to have the origin be an empty string. If you then do a Post On Session, you could pass the full url instead of the endpoint part and it’ll probably work.
Thank you for this suggestion, will try this. I personally did not have much knowledge in Robot Framework most of my knowledge in automation comes from low level frameworks like java, js and python frameworks that’s why i am still confuse on how robot framework structure works. But I really appreciate the suggestion and will try to do this. Thanks a lot!
If you’re familiar with Python, you’ll recognize the types and structures. All in all, Robot Framework is also “just a Python package”. If you have Python experience, it’s also quite easy to implement your own libraries for Robot Framework, so you can create your own keywords.
If you’re using VS Code with the Robot Framework Language Server plugin, you can also Go to definition as right-click action on keywords in your .robot or .resource files and just look at the Python side of things.
Session less keywords are standalone, while with * On Session you have to Create a Session before.
This allows you to avoid using the whole url every time and you can share some settings like cookies or headers that is quite useful if you have multiple requests per test.