Fork me on GitHub
#yada
<
2016-10-17
>
stijn10:10:14

is there a built-in way to manipulate cache-control headers, or should you always use the response in ctx to do that?

stijn10:10:37

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

malcolmsparks10:10:09

@stijn with POST you can return a URL

malcolmsparks10:10:35

But otherwise 'no, not yet' for both questions

stijn10:10:53

OK, thanks

lmergen12:10:30

@stijn what we’re doing is basically injecting an additional interceptor that does this — it’s a crude hack

stijn12:10:13

@lmergen i was thinking of doing the same

stijn12:10:07

anyone knows how would I declare a resource for which the media-type depends on the requested resource?

stijn12:10:19

i'm serving files from a database

stijn12:10:44

it's a bit like yada.resources.file-resource/new-directory-resource, so I assume I need to work with sub-resources here?

stijn12:10:42

in pre 1.1 you could add :representations to :properties but that no longer seems to be the case

stijn12:10:53

ok, got it. :produces can be a function of ctx 🙂

stijn14:10:47

is there an example of authentication + CORS available? i'm not sure how to handle OPTIONS and HEAD for resources that require authentication

stijn19:10:35

ok, it works 😉

stijn19:10:08

OPTIONS doesn't require auth, but HEAD does

stijn20:10:58

@malcolmsparks is it by design that for OPTIONS you have to specify the parameters separately from the other methods?

stijn20:10:33

I'm getting a 400 when the browser is doing a preflight request for a GET, because query parameters are not allowed

stijn20:10:21

and we have to specify them at the method level since parameters are quite different between GET and POST

malcolmsparks20:10:01

@stijn OPTIONS doesn't require auth, because it has to respond to pre-flight requests where auth credentials may not be supplied.

malcolmsparks20:10:22

One of the design decisions I made for parameters was that they could exist at both resource level and method level

malcolmsparks20:10:44

While it makes sense for path parameters to exist at resource level, I'm somewhat regretting that decision

stijn20:10:20

yes, my experience is that the resource level parameters are only for path

stijn20:10:07

but for OPTIONS, since the browser is requesting for Access-Control-Request-Method: GET, shouldn't it allow the parameters for GET?

malcolmsparks20:10:31

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/

malcolmsparks20:10:37

@stijn yes I agree, the whole area of parameters is confusing wrt. the whole of http (all the methods).

malcolmsparks20:10:09

this is an area I'd like to review for yada 1.2, which I'm currently working on.

malcolmsparks20:10:47

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

stijn20:10:08

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?

malcolmsparks20:10:58

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.

malcolmsparks20:10:52

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.)

stijn20:10:11

I believe that makes sense, I'm putting too many swagger deprecation warnings already on parameters that are no longer used 🙂

malcolmsparks20:10:31

yada 1.2 is going to push towards hypermedia APIs and dejure REST, while retaining support for 'street' REST.

malcolmsparks20:10:02

there is also an emerging problem that parameters have different types depending on content type

malcolmsparks20:10:36

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

stijn20:10:57

I'm almost ready with 1.0 > 1.1 migration of a substantially sized API

malcolmsparks20:10:59

but if you use multipart/form-data (which yada totally supports), then there's no need to base64 encode

stijn20:10:34

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

malcolmsparks20:10:45

these minor differences defeat the best attempts to make swagger seamless

malcolmsparks20:10:52

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

stijn20:10:09

absolutely, the code looks a lot cleaner now

malcolmsparks20:10:15

but it turns out that early-adoption of 1.0 provided very important feedback

stijn20:10:24

i also really love how authentication/authorization is done

malcolmsparks20:10:51

thanks @stijn - it was a tough decision to stick with the spec

malcolmsparks20:10:09

my belief if that clojure.spec is going to improve yada a lot, and drive a lot of new improvements.

stijn20:10:32

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

stijn20:10:46

can't wait for 1.2 🙂

malcolmsparks20:10:58

well, you'll have to wait for a bit 😉

malcolmsparks20:10:30

I don't want to rush 1.2, because the opportunity to embrace clojure.spec and do the right thing is very important

malcolmsparks20:10:44

but I think it will be done by Jan/Feb next year

malcolmsparks20:10:17

there are competing tensions between swagger and pure http which have to be navigated

stijn20:10:44

i understand

stijn20:10:56

no rush, it works more than well enough now 🙂

malcolmsparks20:10:36

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

stijn20:10:02

let's look at how awesome pure data is: the problem with options generating a 400 because it doesn't allow method specific parameters is solved in 8 lines of code 🙂