Add URI-M to the URL after each request

[oduwsdl]

Add URI-M to the URL after each request

[shawnmjones]

Agreed. I've been thinking of something similar.

[shawnmjones]

@ibnesayeed The back end already uses an oEmbed endpoint for this kind of behavior, but that is not really designed for humans to consume. We need to be careful with this because there are other future considerations. To complete the oEmbed spec, we will also support, at a minimum, thumbnails as an alternative surrogate to social cards. How do you envision this working in a world where the user will select which type of surrogate they want to produce? Do we have a query string?

[ibnesayeed]

This request is not about the URI of the embedding, but about the interface where the embedding can be created. Including requested URI-M in it will make it statefull and easier to share. So, rather than asking someone to go <Service-Host> then fill the form with a <URI-M>, you can simply say go to <Service-Host>/#<URI-M> which can automatically fill the form and trigger the embed code generation request by hitting corresponding API (say, at, <Service-Host>/embed/<URI-M>). This is similar to how we do it in our CarbonDate service (e.g., http://cd.cs.odu.edu/#http://www.cs.odu.edu/).

[shawnmjones]

I think we are saying the same thing. I'm pointing out that <Service-Host>/#<URI-M> may not be sufficient to describe all possible output states in the user interface page. What if someone wants a thumbnail rather than a social card? MementoEmbed will support thumbnails as an alternative surrogate in version 0.2.

I'm just looking for ways to support all manner of arguments. The only method I know of is query string. I'm not crazy about this because the query string would need to be escaped to work. This would make it difficult for users to construct a URI for use with the user interface, but it would allow users the ability to share URIs from the service. I'm also concerned about using fragments because Is there a better way?

Maybe URL parameters?

• https://doriantaylor.com/policy/http-url-path-parameter-syntax
• https://tools.ietf.org/html/rfc3986#section-3.3

[ibnesayeed]

While query strings are how it should actually be done, but many archival related services (or any other services that have a URI as their primary key to identify resources that needs to be acted upon) prefer that URI argument to the last part of the path after all known path parameters, it is wise to continue that practice as much as possible. The motivation behind this is primarily to avoid escaping as you noted.

Now, getting back to this situation. You can encode the client-side state in two ways, either put structure after segment identifier (e.g., <Service-Host>/#<Type>/<Foo>/<Bar>/<URI-M>) or make some necessary sections part of the path (e.g., <Service-Host>/<Type>/<Foo>/<Bar>/#<URI-M>), whatever works for you.

[shawnmjones]

I originally implemented the <Service-Host>/<Type>/#<URI-M> approach, but after talking to @phonedude, we're going to go with <Service-Host>/<Type>/<URI-M>.