is it normal/required in yada (or HTTP) for the response for an endpoint and the error messages for an endpoint to have the same content-type?

Hmm. Well, yada renegotiates the content type against a (currently fixed) set of error content types. So no.

so if I say that my endpoint is eg “text/csv” I can return other types of errors?

Yes

Or rather, see the existing set in handler.clj

Needs work from me

To make it more configurable

ah, is that in case of exceptions?

I’m manually checking some things and then returning a {:status 400 :body ...}

Yes. But you can replace the exception interceptor chain with your own

Ah. Then you must also set Content-Type in your reponse. Or better still, use yada's conneg functions to neg one

oic

thanks

got that working, thank you!

Good to hear!

@peterwestmacott The way I did it is a bit hacky, but works as well:

(intern 'yada.handler 'error-representations
        (ys/representation-seq
         (ys/representation-set-coercer
          [{:media-type #{"your/content-type"
                          "application/transit+json"
                          "application/json;pretty=true;q=0.96"
                          "text/plain;q=0.9"
                          "text/html;q=0.8"
                          "application/edn;q=0.6"
                          "application/edn;pretty=true;q=0.5"}
            :charset charset/platform-charsets}])))

But responding an error with text/csv is a bit weird maybe

Has anyone explored the idea of avoiding side-effect-y/mutate-y code in the method handler?

The phonebook example, for example, does (db/add-entry db ...) somewhere in the :post handler.

@jonathanj where would you do it?

I haven’t really thought about this super hard, so don’t presume I have anything resembling a good idea. 😉

Well, somewhere else.

If the handler returns data that describes what it expects to happen, something else could take that and actually do the work.

ah, I see. :thinking_face:

[:add-entry {:name "Bob" :number "+1234"}] or some such thing.

I think you'd be hard pressed to find such a DSL that applied to every domain.

Re-frame on the server, I knew it 😉

But, you could ^^ yeah, essentially this.

@borkdude That’s basically where the idea stemmed from.

Except it’s redux, not reframe because I’ve never used reframe.

@jonathanj you might be interested in looking at event sourcing as a pattern 🙂

A speed bump I ran into was what if you need to fetch something from the database?

If there was a function that was handed the request and returned some kind of query/selector data that the handler was called with (eventually) that sort of approaches a solution.

Kind of resembles om.next’s approach, I suppose.

@jonathanj I’m not entirely sure of your problem, but isn’t Manifold deferred something you could utilize here?

Testing something like this and avoiding leaking all manner of business logic into HTTP handlers (that you may forget to do somewhere else) seems a lot easier.

I’m not sure how manifold fits in here, @borkdude. Sorry if I’m being daft.

Maybe you could explain the flow of your request/response some more

Have you seen om.next’s interfaces?

No

Okay, well when you implement your component you can implement an IQuery interface that is called (by om.next’s internal machinery) and should return a piece of data that describes your query (with some kind of datalog-ish looking syntax), internally it gives the query to something (you specified elsewhere), and eventually the data is passed to your component’s render function.

It was just a thought that popped up in my head, in terms of: HTTP request -> handler declares what data it would like to receive -> something realises that query -> your HTTP handler is called with that data -> return some data that describes what the handler intends to happen -> something realises that

HTTP handler = resource in Yada’s terms. Resource declares what data it would like to receive. This depends on the request. It can be realized anywhere using an interceptor?

Hmm, unfortunately the interceptors portion of the manual seems quite incomplete.

An interceptor is just a function from context to context. You can insert them anywhere into an existing chain.

What can an interceptor return?

A context

In particular, how do you spell “eventually” with interceptors?

Manifold

E.g. I made this interceptor to manipulate the Schema to allow an extra parameter:

(defn allow-response-filter-in-schema
  [ctx]
  (if (rb/body-schema ctx)
    (update-in ctx [:resource :methods
                    (:method ctx) :parameters :body]
               (fn [schema]
                 (if (map? schema)
                   (assoc schema
                          (s/optional-key :response/filter)
                          s/Any)
                   schema)))
    ctx))

And I inserted it like this:

(insert-interceptor
         i/process-request-body
         allow-response-filter-in-schema)

@jonathanj In context: https://gist.github.com/borkdude/1023b578e902109c680ba3fd3627a1ee

Don’t know if this is helpful, but just to illustrate interceptors.

Definitely gives me something to think about, thanks.