Fork me on GitHub
#ring-swagger
<
2018-01-12
>
plamen08:01:46

Hello Tommi, lot of thanks for the hint and example! The reason I need it is exactly for documentation purposes - it is for a prototype where just by having swagger/api docs and something to play with by asking/getting data is very useful and needs almost no specific UI to show the concepts, especially when the actual tree/path data is pretty wide and deep. I looked at the example and as it says - it provides the dynamic paths, but doesn’t show them to the end user. Probably would be able to call compojure-api.sweet/api with at runtime constructed maps. Hope that route will bring me further.

plamen08:01:39

But your example provides a very nice way how to achieve it. Thank you again!

ikitommi08:01:40

if you know the nesting in advance, you can generate the routes with normal for, reduce etc.

mgrbyte21:01:33

@ikitommi having trouble with c.api making application/edn work as the default format. I've set :formats (-> (m/create) (assoc :default-format "application/edn")) in my app, but i'm getting json formatted data back no matter what. I've been digging around the examples and wiki for a while now, must be missing something obvious - could you point me in the right direction pls?

mgrbyte00:01:53

Getting the following from testing simplest thing (fallback 404 handler):

{:response
 {:status 404,
  :headers {"Content-Type" "application/edn"},
  :body
  #object[java.io.ByteArrayInputStream 0x683795a5 "java.io.ByteArrayInputStream@683795a5"],
  :muuntaja/format "application/json"}

ikitommi19:01:48

@mgrbyte Muuntaja instance is stateful and caches the values given in creation (for speed), despite it’s implemented as a Record. I wrote an issue to re-implement it as a Protocol to avoid confusion. But the correct way is to transform the options and create a Muuntaja out of those, eg. (-> (assoc m/default-options :default-format "application/edn") (m/create))

mgrbyte10:01:26

@ikitommi thanks very much, that solved it :thumbsup:

mgrbyte10:01:44

fwiw, I'm using the latest c.api, with spec - decided to make all clients pass EDN as it makes the validation much easier. I was finding that e.g making certain values in maps conform to a namespaced keyword (datomic ident form an enum for example) ...

mgrbyte10:01:24

was a lot more code to write in order to have a single spec to conform to.

mgrbyte10:01:03

Perhaps I'm "doing it wrong"? 🙂

mgrbyte10:01:43

I'm making good progress with my authz stuff, will try and extract an example repo when I'm done and feedback to the project.

ikitommi15:01:26

@mgrbyte is there still an issue spec + with namespaces keywords, could you paste an example? looking forward to the authz stuff 🙂

mgrbyte15:01:21

No direct issue, other than JSON doesn't natively support keywords, so not sure there's a (direct) coercion path without writing custom code

mgrbyte15:01:12

e.g clj: {:myms/scheama-attr :a-ns/some-ident} - a client supplying something that maps to this in json?

mgrbyte15:01:07

In the clojure side of things, want to describe :myns/schema-attr with a spec. This needs to work for both the client and the app itself. could write two specs, but not sure that trumps making the client(s) use EDN.

ikitommi19:01:48

@mgrbyte Muuntaja instance is stateful and caches the values given in creation (for speed), despite it’s implemented as a Record. I wrote an issue to re-implement it as a Protocol to avoid confusion. But the correct way is to transform the options and create a Muuntaja out of those, eg. (-> (assoc m/default-options :default-format "application/edn") (m/create))