This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2017-01-09
Channels
- # beginners (38)
- # boot (160)
- # cider (143)
- # cljs-dev (62)
- # cljsjs (2)
- # cljsrn (3)
- # clojure (278)
- # clojure-austin (8)
- # clojure-brasil (5)
- # clojure-greece (2)
- # clojure-italy (11)
- # clojure-russia (188)
- # clojure-sg (2)
- # clojure-spec (118)
- # clojure-uk (103)
- # clojurescript (87)
- # core-async (8)
- # cryogen (2)
- # cursive (12)
- # datomic (119)
- # emacs (13)
- # hoplon (4)
- # immutant (12)
- # off-topic (12)
- # om (54)
- # om-next (5)
- # onyx (1)
- # pedestal (2)
- # portland-or (2)
- # re-frame (58)
- # reagent (18)
- # ring-swagger (18)
- # rum (4)
- # spacemacs (4)
- # specter (3)
- # untangled (65)
- # yada (25)
@ikitommi looks promising!
"application/yaml" coerce/query-schema-coercion-matcher
looks suspicious 🙂 AFAIU, Yaml and Msgpack are similar to JSON but still have some differences, e.g. "YAML has many additional features lacking in JSON, including comments, extensible data types, relational anchors, strings without quotation marks, and mapping types preserving key order.". Whatever the library decision about coercion for these formats is it should be in the readme somewhere at the forefront. One of the solutions is to turn off coercion for additional formats altogether. I.e. make 1.2.0 fully support out-of-the-box only JSON, Transit and edn.
@metametadata Thanks and good point about the YAML (and it’s application/x-yaml
not application/yaml
). I’ll write few tests and see how the two extra formats behave with & without coercion. With pre 1.2, a json-schema-coercion-matcher
is used with all responses. Actually - the response coercion could be (constantly nil)
for all. Responses are generated by handler, so all clojure types are available...
does it make sense to use compojure-api for a website (mostly html responses, small amount of json endpoints) ?
I love path/query/form params validation/coercion, pure compojure doesn't do this, so considering compojure-api for everything
I don't see any reason to not do this, but there's one small thing which makes me wonder: -api in the name of the library 🙂
I'm wondering if it does stuff like for example adding some response headers (API security, content related etc) which make no sense for text/html responses?
@sickill it's totally ok :) you can use the endpoint macros (`GET`...) also in plain ring/compojure-app, they don't have to be under api
- they produce ring handler functions. Or you can add a undocumented
subroute under api
which has non-compojure-api routes (like ring asset handlers).
if you GET
s are outside of api
, the reverse routing does not work and to read JSON/EDN you have to mount a request-formatter yourself.