HTTP session tracking through base URL "resource"?

Question

A little background: We're currently trying try specify an HTTP API between a couple of vendors so that different products can easily inter operate. We're not writing any "server" software yet, nor any client, but just laying out the basics of the API so that every party can start prototyping and then we can refine it. So the typical use-case for this API would be being used by (thin) HTTP layers inside a given application, not from within the browser.

Communication doesn't really make sense without having session state here, so we were looking into how to track sessions typically.

Thing is, we want to keep the implementation of the API as easy as possible with as little burden as possible on any used HTTP library.

Someone proposed to manage session basically through "URL rewriting", but a little more explicit:

• POST .../service/session { ... }
• => reply with 201 Created and session URL location .../service/session/{session-uuid}
• subsequent requests use .../service/session/{session-uuid}/whatever
• to end the session the client does DELETE .../service/session/{session-uuid}

Looking around the web, initial searches indicate this is somewhat untypical.

Is this a valid approach? Specific drawbacks or pros?

The pros we identified: (please debunk where appropriate)

• Simple on the implementation, no cookie or header tracking etc. required
• Orthogonal to client authentication mechanism - if authentication is appropriate, we could easily pass the URLs to a second app that could continue to use the session (valid use case in our case)
• Should be safe, as we're going https exclusively for this.

---

Since, PHPSESSID was mentioned, I stumbled upon this other question, where it is mentioned that the "session in URL" approach may be more vulnerable to session fixation attacks.

However, see 2nd bullet above: We plan to implement~specify authentication/authorization orthogonally to this session concept, so passing around the "session" url might even be a feature, so we think we're quite fine with having the session appear in the URL.