Clojurians Log v2

Well that's odd. I removed (io.pedestal.http.body-params/body-params) interceptor and the :json-params are now present and correct. So it's implicitly active now and we shouldn't explicitly add it ourselves?

Are you using io.pedestal.connector or io.pedestal.http?

io pedestal.connector. I've removed all references to io.pedestal.http

I'm using rc-1 btw

The default interceptors from the connector include the body-params interceptor.

Good to know. That's an important change from previous versions so probably worth including somewhere obvious that I can't think of right now. <- probably one of the dumbest things I've said, I realise

https://pedestal.io/api/0.8/io.pedestal.connector.html#var-with-default-interceptors > It is expected that an application under active development will not use this function, but will provide its own interceptor stack explicitly.

I'm using that function indeed and didn't see that warning. Thanks Howard

Going to investigate exactly which interceptors are provided and what I should explicitly include instead. Although if it's close to what I want I may just keep it. Should I not rely on it?

Seems like a pretty good list of default interceptors!

Essentially, I want the ability to change it in the future without worrying about backwards compatibility. And as the docs say, you can configure the interceptors for greater security if you care. Finally, each application is a bit unique and may have special needs ... addressing that directly by not using default-interceptors is more maintainable in the long run regardless of what happens to that function in the future. In the past I've designed things where there's a default set of interceptors (or such) that you are expected to modify; that was always a disaster as it was impossible to see in the code, at a glance, what was really going on. Less is more.

I’ll configure them explicitly and stop using the default interceptors function. Thanks for explaining.

So I've had time to reflect and replace (conn/with-default-interceptors) with my own required base interceptors and only added body param and query param interceptors where I need them and I'm much happier with the code. I understand more about pedestal as well - this came at the perfect time.

@hlship perhaps some of my confusion until yesterday was assuming that since conn/with-default-interceptors was heavily used in all examples on the web site that it was recommended practice to use this function, but what you said yesterday suggests the opposite. Perhaps the web examples should instead explicitly define base interceptors, which presents the opportunity to discuss which are provided by pedestal and where they are most appropriately used. Newcomers to pedestal might then start with better practices (unlike me! 🙂) If you agree, I'm happy to make a PR when I have the time.

Maybe it could be renamed from with-default-interceptors to with-example-interceptors?

As someone who skimmed over the 0.8 guides yesterday and who is migrating from 0.6, I did find I needed to explicitly include some interceptors from the default set to regain the 0.6 setup: • secure-headers and cors were previously setup through the service map, now interceptors • and I had to add the not-found, content-type and query-params interceptors I concur with @sirwobin's suggestion.