This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2017-02-24
Channels
- # aws (3)
- # aws-lambda (1)
- # beginners (16)
- # boot (36)
- # cider (3)
- # cljs-dev (90)
- # cljsjs (1)
- # cljsrn (27)
- # clojure (240)
- # clojure-austin (1)
- # clojure-berlin (3)
- # clojure-dusseldorf (2)
- # clojure-france (2)
- # clojure-germany (12)
- # clojure-russia (19)
- # clojure-spec (20)
- # clojure-uk (56)
- # clojurescript (218)
- # clojurex (1)
- # cursive (21)
- # datomic (10)
- # events (1)
- # hoplon (18)
- # instaparse (19)
- # jobs-discuss (3)
- # lein-figwheel (3)
- # luminus (3)
- # lumo (14)
- # off-topic (4)
- # om (76)
- # onyx (67)
- # protorepl (12)
- # re-frame (54)
- # reagent (35)
- # ring (2)
- # spacemacs (5)
- # specter (2)
- # sql (11)
- # untangled (144)
- # yada (34)
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
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
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 -
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
(but I had to check!)
(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.
@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