ring-swagger & compojure-api
rbarker 2018-08-20T06:44:37.000100Z

I can’t find any specific documentation that lists all the meta-data that you can explicitly provide when creating an endpoint. The best that I can find is this snippet https://github.com/metosin/compojure-api/wiki/Swagger-integration#just-data We aren’t using Schema or Spec for validation but still want to document the application routes with Swagger and are using compojure-api

ikitommi 2018-08-20T06:52:09.000100Z

@sooheon Tested and your initial code seemwork ok (2.0.0-alpha23)

ikitommi 2018-08-20T06:52:34.000100Z

ikitommi 2018-08-20T06:53:33.000100Z

@rbarker there is (<http://compojure.api.help/help|compojure.api.help/help>) for the repl.

ikitommi 2018-08-20T06:54:05.000100Z

but, if you only need swagger, you can use :swagger for everything.

ikitommi 2018-08-20T06:54:34.000100Z

(GET "/api" []
  :swagger {:description "endpoint", :responses {200 ...}}

rbarker 2018-08-20T06:54:45.000100Z

is there a list of everything that you can put in that map for the :swagger key?

ikitommi 2018-08-20T06:56:15.000100Z

anything that can be set via swagger, here’s the spec: https://github.com/OAI/OpenAPI-Specification/blob/master/versions/2.0.md

ikitommi 2018-08-20T06:56:38.000100Z

there is a sample in ring-swagger too: https://github.com/metosin/ring-swagger#more-complete-example

ikitommi 2018-08-20T06:57:27.000100Z

the :parameters and :responses can use Schema (or Spec) definitions instead of JSON Schema definitions.

ikitommi 2018-08-20T06:57:57.000100Z

sorry, no guide. happy to see a PR of an example c-api app with just swagger docs.

jdt 2018-08-20T12:40:06.000100Z

Please don't put yaml back in as a default. My company explicitly removed yaml support because of the potential for yaml bomb denial of service attacks, as the yaml parser use by ring/swagger definitey succumbs to this problem.

jdt 2018-08-20T12:41:02.000100Z

If you add it back in as a default, since we now rely on that non-yaml-default behavior having upgraded to compojure-api 2.0.0, then it reintroduces the security risk.

jdt 2018-08-20T12:55:27.000100Z

Hmmm, this causes existing code to break. Apparently muuntaja.format.msgpack/with-msgpack-format no longer exists and I have code that uses it in my api configuration map: e.g. :formats (m/create (-&gt; m/default-options (msgpack-format/with-msgpack-format)))

ikitommi 2018-08-20T13:02:09.000100Z

@jdt the with-* were removed, there is muuntaja.core/install helper to add the modules. The changelogs should show how to use it

ikitommi 2018-08-20T13:03:36.000100Z

not putting them back

jdt 2018-08-20T14:43:46.000100Z

Hi Tommi, so upgrading various muuntaja and compojure-api libraries as discussed in the main thread has fixed my encoding exception, and I appear to be returning the above response from the server. However the http client is just hanging on a GET from the response. In testing an identical get and identical server response in a plain immutant web app without compojure api it works fine (using {:as :stream} in the clj-http client request). But it isn't working in the compojure-api scenario. Is there some special streaming response I need to specify with compojure-api?

jdt 2018-08-20T14:52:38.000100Z

compojure-api streaming failure non-compojure-api works, closer but not working yet.

jdt 2018-08-20T15:10:26.000100Z

I'm wondering if it isn't something about the client Content-Type headers including application/json, and that being a mismatch for the the headers specifed in the sse-channel response ("text/event-stream" - as above).

jdt 2018-08-20T15:12:04.000100Z

(not shown in snippet, will try without).

jdt 2018-08-20T15:18:09.000100Z

Yeah, client inclusion of client content type specifications makes no difference, the GET hangs on the sse-channel response via compojure-api. Not sure how to debug the up-stack activities of compojure-api after I return the value, suggestions?

jdt 2018-08-20T15:22:44.000100Z

curl says "empty reply from server".