Fork me on GitHub

Does yada deal with API versioning? I thought I saw something related at some point but I can’t find it anymore.


Hey! (yada [1 2 3 4]) maps to an error with text/html but to an expected JSON vector with application/json. Perhaps the multimethod render-seq for text/html could check that the provided value looks like a hiccup structure before trying to render with it and use the edn->html otherwise. What do you think?


It's an idea. I think the hiccup coercion I put in recently is taking things a little too far. I doubt it has serious value beyond beginners examples. I think I'll revert back to rendering a vector as before.


I kind of like the fact that it has nice html output out of the box


but I guess e.g. Swagger is more important since browsers are lousy tools for inspecting an API anyway


@aspra Only in that you can define your own mimetypes, which allows content negotiation to negotiate the version to use. You can of course use bidi and path-params as routes are easily composed, but the you lose content negotiation. Did you have something else in mind?


@macroz I like html rendition of maps and seqs. I'm not certain Swagger does a better job of rendering the response. Postman and other browser plugins are useful. But 'easy' means 'close at hand': often it's some use getting the html rendition of a map because you might not have those alternatives set up.


Yes, ideally coercion to text/html would produce something nice as result. Anyway, keep up the good work! Time to sleep simple_smile


@malcolmsparks: So i want to add logging to every request, I think that means that i want to make an intercepter that does the logging magic, but i am not sure how to add it to the intercepter chain rather then replace the intercepter chain… or do i just append it to the default intercepter chain? or am i going down the wrong rabbit hole?


I usually insert somewhere in the default interceptor chain. You have to get a bit familiar with the interceptors to know where you want to insert. For logging, I'd say pushing it onto the front


But yes, reference the default interceptor chain explicitlt, or post process the entire tree and modify the resources.


Each resource is a data structure you can manipulate prior to creating the handlers


You can also modify handlers, before requests or dynamically whenever you like. It's all data transformation


Is there a idiomatic place to put it?


or is it up to the use case entirely


It's up to your usecase. The further down the chain the more data you have to log. Downside is any exceptions that occur prior to your logger will mean your logger isn't called.


For example if you were to add it to your phone book example (which has been a life saver btw) where would you put it?


At the front I think


in the resource declarations? or after the handler had been constructed in api.clj


In the resource declarations


But I believe either approach will work


Not at my computer right now!


Thank you very much for your input simple_smile Your the best!