Would this be considered good practice or is there a better way to do this?
No, this doesn't seem to be ideal.
The biggest problem I see is that you put a session id into the HTML of a page. It is best practice to make session cookies httpOnly to make XSS a bit harder to exploit. By putting the session id into the HTML, you leak that information in case of XSS, thus making httpOnly useless.
This may also be a problem if sensitive data is stored in a session, as someone who hijacked one session or account now has access to all sessions. The impact seems minor, but it doesn't seem ideal and may be a problem depending on the application.
Additionally, you don't have any CSRF protection which - while bad practice in general - doesn't have a security impact in this case as this isn't a very sensitive action and an attacker would need to know the session id, which they don't. Still, it doesn't seem ideal and also violates RESTful.
Finally, it's never a good idea to put sensitive data in a URL, it should instead be submitted via POST as it may otherwise leak in various ways. Again, this is likely not a security issue, as the data is useless as soon as it is used, but it doesn't follow best practices (and may be a problem, eg when the delete didn't work).
I would suggest to use ids that are independent of the actual session id, and to submit them via POST instead.