This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # alda (5)
- # bangalore-clj (1)
- # beginners (9)
- # bigdata (1)
- # boot (51)
- # carry (1)
- # cider (9)
- # cljs-dev (22)
- # clojars (39)
- # clojure (118)
- # clojure-brasil (1)
- # clojure-czech (8)
- # clojure-france (2)
- # clojure-italy (5)
- # clojure-korea (9)
- # clojure-russia (9)
- # clojure-spec (17)
- # clojure-uk (42)
- # clojurescript (48)
- # core-async (1)
- # emacs (3)
- # figwheel (1)
- # funcool (3)
- # hoplon (39)
- # klipse (51)
- # lein-figwheel (4)
- # leiningen (2)
- # luminus (5)
- # off-topic (245)
- # om (18)
- # onyx (19)
- # parinfer (1)
- # pedestal (18)
- # re-frame (47)
- # reagent (19)
- # ring-swagger (1)
- # specter (18)
- # untangled (93)
- # vim (8)
- # yada (56)
is there a built-in way to manipulate cache-control headers, or should you always use the response in ctx to do that?
same question for the Location header on POST response. I thought I had seen this somewhere but can't find it back in the docs/code
@stijn what we’re doing is basically injecting an additional interceptor that does this — it’s a crude hack
anyone knows how would I declare a resource for which the media-type depends on the requested resource?
it's a bit like yada.resources.file-resource/new-directory-resource, so I assume I need to work with sub-resources here?
in pre 1.1 you could add
:properties but that no longer seems to be the case
is there an example of authentication + CORS available? i'm not sure how to handle OPTIONS and HEAD for resources that require authentication
@malcolmsparks is it by design that for OPTIONS you have to specify the parameters separately from the other methods?
I'm getting a 400 when the browser is doing a preflight request for a GET, because query parameters are not allowed
and we have to specify them at the method level since parameters are quite different between GET and POST
@stijn OPTIONS doesn't require auth, because it has to respond to pre-flight requests where auth credentials may not be supplied.
One of the design decisions I made for parameters was that they could exist at both resource level and method level
While it makes sense for path parameters to exist at resource level, I'm somewhat regretting that decision
but for OPTIONS, since the browser is requesting for
Access-Control-Request-Method: GET, shouldn't it allow the parameters for GET?
parameters needs a bit of a rethink, I also believe we should not be too restrictive about parameters - I quite like this article: http://olivergierke.de/2016/10/evolving-distributed-systems/
@stijn yes I agree, the whole area of parameters is confusing wrt. the whole of http (all the methods).
this is an area I'd like to review for yada 1.2, which I'm currently working on.
yada 1.2 is going to be a significant update, moving from prismatic schema to clojure.spec - I'm currently working through the details of resource maps defined in clojure.spec
and I assume that will also mean that parameters schemas are dynamic in the sense that extra parameters will not result in a bad request?
I'd be very appreciative of feedback about anything in yada 1.1 people think isn't working out very well, because there's an opportunity in yada 1.2 to revise these things.
yada has to make some concessions to how swagger has defined parameters, and that's meant path parameters have been defined the way they are (along with query params, etc.)
I believe that makes sense, I'm putting too many swagger deprecation warnings already on parameters that are no longer used 🙂
yada 1.2 is going to push towards hypermedia APIs and dejure REST, while retaining support for 'street' REST.
there is also an emerging problem that parameters have different types depending on content type
for example, suppose you want to upload binary images - if you want to support application/json (JSON doesn't support binary inclusion), then you'd base64-encode your image data
but if you use multipart/form-data (which yada totally supports), then there's no need to base64 encode
most of the things that I had to hack around in 1.0 are gone from the code, but there are a few things that could be better, so I'll write that up if that's any use
thanks so much for embracing 1.0, it was a big jump to 1.1 but I really felt it was an important refactor in the end, embracing the plain-old-data approach of the Clojure philosphy
my belief if that clojure.spec is going to improve yada a lot, and drive a lot of new improvements.
yeah, you have to get used to the HTTP jargon to understand it properly, but it totally makes sense. and the order of the interceptors makes it all integrate easily
I don't want to rush 1.2, because the opportunity to embrace clojure.spec and do the right thing is very important
there are competing tensions between swagger and pure http which have to be navigated
the more I understand http, the more I appreciate the work of the designers behind it - the protocol is an immense landmark achievement and drives so much innovation these days