0

I'm making an application where the front-end can display resources both as themselves or within a modal. Of course, when the server gets a request for a resource in HTML, it's going to include a layout (with a <head>, maybe a header and footer in body, and so on). However, if I want a modal with the resource information, I do not need that layout.

How should I ask the server to serve me its resource with or without a resource?

I doubt anything is already present in standardized headers, but is there prior art on standardizing that kind of behavior?

After some thought, I posit that information about that request should go in headers. Here's where I thought it should not go:

  • Query string: It could have gone as a parameter in the query string, but the preference for a layout does not change the resource I'm asking for, only its "format". For example, imagine an anchor link to my resource, and the front-end decides this should open a modal, except on a middle-click. The URL should stay the same.

  • Accept/Content-type: The content I'm trying to get is HTML (in one instance), and whether or not I have a layout does not mean I suddenly don't obey to its rules.

  • X-Requested-With header: Of course, anytime I request the content of a modal in XHR, I should not get a layout, but what if I have a script on my page that fetches a new page dynamically to have it replaced? Moreover, the XHR header would implicitly carry the meaning of not serving the layout without the client/request having any say.

I'm mostly looking for either prior art towards solving that problem, or early proposals about how that could look like, following in the path of the HTTP spec.

1

Do not invent your own headers. And please avoid using headers to detect which content you should serve. There are legitimate use cases for this, but in general this makes your backend much more difficult to debug.

The full-page and modal variant of the page represent the same resource​, so it can be argued that they should have the same URL. Using a query parameter to distinguish between different presentations would then be cleanest, e.g. https://example.com/resource?layout=fragment. It is normal to have multiple URLs that represent the same resource, the HTML documents are then linked via <link rel=canonical ...> if SEO is important for your project​.

Loading HTML fragments from the server is super simple, and I've also done it. However, mixing URLs for your users that should be linkable and URLs for your JavaScript may not be the most maintainable solution in the long term. The requirements for these two kinds of URLs are quite different. E.g. you do not want to see parts of your internal API in Google search results. You do not want to accidentally link to an internal URL. Then, it may be best to move all endpoints required by your frontend JavaScript under /api/. Whether such an URL design is sensible probably depends on your existing URLs. I'd lean towards it if your URLs are more like generic pages (/?id=1234), less so if they identify entities with available actions (/cart offers actions /cart/add-product and /cart/checkout).

0

Query string: It could have gone as a parameter in the query string, but the preference for a layout does not change the resource I'm asking for, only its "format".

I would dispute this- in my opinion if it's in the HTML, it's part of the 'resource'. It may have formatting implications, but that doesn't make it not the resource.

For example, imagine an anchor link to my resource, and the front-end decides this should open a modal, except on a middle-click. The URL should stay the same.

Why? If the behaviour is being interfered with regarding the type of request, why does the url have to stay the same? When you run your code on click and build your xhttp request, appending the query is trivial.

In short, I'd go with the query string approach.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.