I'm planning to send a user's session ID as a URL parameter which will be AES encrypted. I don't think my app has any link sharing problems. Is this idea feasible? Is it safe?
If your session ID is truly random, there is no additional security in AES-encrypting it. If, however, it is not random, I would strongly recommend against doing so, for reasons similar to why no-one sane uses predictable session ID tokens.
Also, if you're not using SSL, your traffic can be sniffed. This means that, no matter how much you encrypt the token... it is still plainly visible. (Well, your traffic can be sniffed with SSL on, but it's a bit more complicated)
It's a bad idea.
Encrypting the session identifier has no real impact on the security of your application. If the traffic is sent in plaintext (without SSL) anyone is able to read that encrypted session ID and then use it to impersonate the legitimate user.
Let's say my session ID is
12345. Every time I want to go to your house you ask me about my session ID, I'm gonna yell it from behind the door and someone might overhear it. To solve the problem, we encrypt the session ID, so it becomes
OF&HN7907fynNYH. That changes nothing, someone will still overhear it and is able to repeat it.
As for the other part of your question, about putting the session ID in the URL. The reason I think it's a bad idea because the URL can be used and stored in so many other places; in proxy logs, can be bookmarked, or stored in error reports. This subject has been discussed before here.
Is it feasible? Yes. It's a standard pattern for cookie-less session and was a de rigueur pattern for session management in JSP app for a number of years.
Is is a good idea? No, for a couple of reasons.
One of the primary vulnerabilities for a site that has a concept of session management is session hijacking, where the session id is sniffed and stolen, as Sébastien mentioned. The URL is the most vulnerable location that could possibly be chosen for this identifier. It's visible in the browser, on the wire (if not using SSL) can be bookmarked and easily shared.
It can impede usability. This is not a security issue, but if the parameter is embedded in the URL, as JSP ids often were, it can prevent legitimate sharing and bookmarking, and lead to user frustration when they try to return to a bookmarked page once a session has expired, only to have the application tell them that the URL is invalid, and they have no idea how to get back to the page.