Fork me on GitHub

Ideas about the new validation errors, comments welcome:


Hey, I am trying to do something a little unorthodox and I was wondering what is responsible for turning the :params key in a request into the lovely :query-params key in the request?


I thought it might be compojure.api.middleware/api-middleware but I couldn’t figure out how it gets the swagger information


Context: I am converting our API to use the compojure.api resource style stuff. However we also have websocket subscriptions that work the same way. So I have the :handler function as a defn and I would like to use that same function to handle the WS request too. However that handler is expecting the parameters in :query-params but the WS is passing the params as :params to mimic Ring.


@kasuko it’s it other way around, api-middleware installs ring.middleware.params/wrap-params which reads :query-params (and others) into :params. You could write a custom middleware to do this the other way around. With the latest alpha, you can also add middleware directly to resources.


the swagger information is collected by the api function ( it reads the paths and transforms their information into swagger definitions, and merges the top-level swagger data to it. Data is injected into the request (together with the reverse-routing information to enable bi-directional routing) and by so, is available to all routes under the api. the swagger-docs handler just reads it from the request.


all Routes self-contain all the ring-swagger-data, you can print any Route (`api`, context, GET, resource, …) in the repl to see how their data, including the swagger-stuff.


hope this helps.


and calling compojure.api.routes/get-routes on a Route gives the cumulative routing tree, with all the extra data.


@ikitommi , im taking a look into your example of a spec error what does the :spec "(clojure.spec.alpha/keys :req-un [::a])stands for? this is the error msg that will be sent to the client if it fails to meet the spec?


@ikitommi thanks! Looks like my task isn’t going to be as easy as I had hoped!


@plins that would be the s/form of the spec. The ::a shouldbe :user/a as its expanded there


could be under :form...


it would be really nice to set a custom msg if some validation fails, sometimes the errors get quite confusing (specially to a third party client consuming the api with no knowledge of clojure at all)


custom message per schema/spec or per field?


per field would be perfect, but is it possible? maybe i want the impossible here 😛


added already a :reason field to spec-tools Spec records, allows per "field"


thanks 🙂


changing subject here, is there a canonical way of setting a default value for a field? im struggling with limit and offset values


Schema doen't have that, but could/should


ive read some discussions on github regarding this topic but wasnt able to figure out how to do it


default for docs or Real default?


real default, in eg. if the user do not provid an offset and limit i could just accept the request (instead of 400) and use some default value


its doable by parsing the request by hand but id like to avoid that


letk-syntax has that, but if you define schemas as data/maps (e.g. :body or with resources), there isn't a mechanism for that in Schema core.


but, there is one in schema-tools (and will be in spec-tools).


but to get the defaults in, you need to run explicitely confom or coerce with a conformer/coercer that applies the defaults. And the original spec/schema needs to have a :default data Needs some plumbing to get working now.


Today, I would just merge in the defaults. Far from good, but works.


@kasuko, maybe do (update request :query-params merge (:params request)) before the handler in the ws?


@plins could you write a issue to schema-tools to support per schema valisation error :reason? Now only in spec-side. Would work the same way with both libs.


sure! thanks for the insightful info 🙂