good morning/afternoon

Hi

what would be the best way to implement GET /resource.json and GET /resource.png with yada? Would like to have these two media types configured on a resource

in other words how to get content negotiation based on the file extension in a URL

Have a look at the implementation here: src/yada/resources/file_resource.clj @sickill

1. You could generate yada resources

2. You could use reactive negotiation (yada doesn't support that yet, but I think that it would be a nice idea)

3. You could use subresources (like the file-resource example does)

It's very idiomatic to use suffixes like this, but strictly unnecessary because the response will set the Content-Type, so it's duplicate information

But for other reasons it's good to keep to the idioms (like users saving the file on their local OS)

I think all this is a throwback to when most webservers were just serving static content from file systems

yeah, exactly

You could set a subresource on resource, and use path-info to give you the suffix

The downside of subresources is that they yield no 'static' information about a resource (for swagger, etc.)

and also when I want to use png in a <img> tag I can't really tell browser to use /resource + specific media type header

but one response to that complaint is that the web is meant to be dynamic, and that attempts to make it static (like good old IDL, RPC, SOAP, etc.) is misunderstanding the dynamic nature of the web -

so suffix is a workaround for this particular case

one argument is that we should be programming clients to be responsive to change, not hardcoding in paths and content types

@sickill good point about the <img> tag.

you could generate yada resources for all the suffixes you support - that's the main reason bidi and yada are based on data structures

I don't think browsers send Accept: png, jpg, blah when requesting resource specified by src attr of img tag, but I may be wrong

or you could copy-and-paste 😉

I fully agree about what you say about dynamic nature of the web, and yada does great job here

@sickill when I get a jpg image in my browser (chromium), the request header is Accept:image/webp,image/*,*/*;q=0.8

so I think you're wrong

allright!

(but I had to check!)

so probably I don't need the suffix at all

(actually I have to support it for legacy reasons, but nice to know it's not strictly necessary)

I had a case yesterday where I could have used a suffix per content-type! Linking to files (oh I want a csv!) is much easier to say "Oh, curl with this header" vs "click http://example.com/resource.csv" It's a shame browsers don't have a nice UI in some way for selecting the content type you want.

@dominicm exactly

@malcolmsparks thanks for the tips

@malcolmsparks @dominicm so I found one more reason to use explicit suffix to force resource representation: png vs gif (animated) to be used in <img> tag. Browser sending Accept:image/webp,image/*,*/*;q=0.8 means the browser+server make the choice for me, which in this case isn't what I want

this problem wouldn't exist if we had separate content-type for animated gifs (not starting with image/), and a separate html tag for animations (or maybe <video> supporting animated gifs)