@lmergen just got back home to test, yeah manifold.deferred/chain works perfectly! One additional step was required and that was to convert the body with byte-streams/to-string

That does mean that the docs under https://juxt.pro/yada/manual/index.html#deferred-values aren’t going to work out of the box for people.

You mean the http response body ?

You should do (http/get ... :as :json) to coerce the http response body into a json object

@kingoftheknoll One problem with using only the body, is that you lose the headers from the response, and other metadata too.

You might be able to merge it into (:response ctx) though

@kingoftheknoll: look at process-request-body multimethod implementations in the code. You dan provide your own consumer if necesssary. Docs are somewhat behind the curve here

@dominicm totally, I just hadn’t added headers yet. I’m just stuck at taking the value of the request body. @malcolmsparks I took a look at at process-request-body and I was surprised that I didn’t see a case for both EDN and JSON. However the docs say :consumes and :produces can coerce those values as I’ve done above. That aside I’d like to try A/B’ing using yada and a plain Aleph handler to see what solution comes out most clean. But I’m struggling to find in the Bidi docs or source how to do the partial match like you’re doing with the :path-info? true

yada resources satisfy bidi's Matched protocol, so when used in the right-hand side of a route pair, can match on a pattern even if the path is not fully consumed.

there are implementations for process-request-body in request-body.clj

for both application/json and application/edn

I see it’s under parse-stream

Then I don’t fully understand how my code above doesn’t coerce the body

@imre did some refactoring there recently

Gotcha, back to the bidi question, so [“/v2” handler] would match anything starting with that root address? Such as “v2”, “v2/hamsters” and “v2/rabbits”

Yes. It has the opportunity to at least. Most bidi Matcheds will only succeed if the remaining path is 0 length, but they can succeed even with a non-zero path. It's up to them

See handler.clj, line 225

So if I’m reading this correct the handler itself determines if it’s a match?

Yes

Interesting, thanks. I’m going to keep trying to get the coercion of the request body to work, see if I can get the above code to work.

thanks for your help

What’s the difference between :produces and :consumes at the top level of a resource https://juxt.pro/yada/manual/index.html#_resource_models vs. within the methods maps?

Method level takes priority.

I'd need to check the code as to whether any merging takes place

I suggest you specify at method-level only

understood, the consumes key is what decides how to coerce correct?

It determines whether the content is rejected or accepted.

The request's Content-Type header determines which implementation gets used

I’m stumped then because i’m using Content-Type for application/json and I’m still getting a manifold stream

I’ll try making a new resource and just try it at the top level without the subresource.

test it out

Can you explain what you're trying to do? Upload a large json body?

I’m an idiot, I was trying to pull out the :body from the :request in context. Where the coerced value in just in :body at the top level of context

So I was looking at (-> ctx :request :body) instead of (-> ctx :body)

When you say you're getting a manifold stream, you mean on the response? Consume and produce are separate stages in yada. I'm a bit confused. On the request, there is no conneg. The consumes is just to allow for a 415 and give swagger something to keep it happy. There is no conneg. The request header Content-Type determines the method of the process-request-body multimethod that is called. The default impl here slurps the whole body into a single string with bs/to-string. That's fine fo most cases- we don't usually have to stream json. If you need that you can override that impl with your own that looks more async like the multipart code.

Ah! Yes. That's because the request in the ctx is the original request. The body therein might have been already processed.

But you are certainly no idiot!

Yada does not mutate the :request value

It seems impolite to do that

Most certainly lol. Coming from most other webservers the thought is “lets look at the request”. I used clojure.tools.logging/spy to look at ctx that’s how I figured it out.

Even though I’ve been learning clojure for over a year this is my first real project in it. And while I’m quite comfortable with immutablity and FP there’s still those times where something you take for granted in the OOP world is awkward in FP land.

Thanks so much for your patience with this newbie!

No problem. I'm on a cycle ride and just checking in at intervals

I hope you manage to figure it out. Ultimately you can always replace any or all of yada's own interceptors if you need full control but usually the defaults yada gives are fine. Plus you can modify the context however you like, keeping yada's overall design but bending it to your will

There is going to be a full reference of the yada context, what yada puts in it.

And when