@imre: thanks, that works fine!

Hi, I've just been experimenting with dev/src/yada/dev/upload.clj in the yada repo, but for some files (I was using audio files), whilst there is no reported error, the uploaded file is not the same size as the original file. If I base64 encode the audio file then it does upload correctly. Any ideas as to the issue here?

I was not able to keep returning the resource id by overriding MessageBody...what was goal?...to keep the structure of the returned Json...id of the resource and the like, but sometimes I get:

com.fasterxml.jackson.core.JsonGenerationException: Cannot JSON encode object of class: class yada.resources.classpath_resource$new_classpath_resource$fn__49347: yada.resources.classpath_resource$new_classpath_resource$fn__49347@2745aee6

@malcolmsparks: just trying to get swagger going on my api... finding it stumbles over vanilla handlers (attempting to coerce them to resources with #'yada.swagger/HandlerToResource and bodies which are the result of a custom consumer (e.g. TempfilePartial) ... you want a PR sometime soon ?

@mark.melling: I'm going to release 1.1.14 in a few hours which may solve these upload problems

hello guys I cannot find in the doc (070_methods.md) a formal definition of what a PUT should return (I always see the it returns a 204

I would like it to return 201

The response is a map...` {:error {:message "ERROR: relation \"users\" does not exist"}}` but for some reason the returned body is empty, what am I missing?

I see a conditional on (ctx/exists? ctx) 204

so I need to modify some property to "declare" that the resource was not existing, is that right?

@richiardiandrea: exactly

"If the target resource does not have a current representation and the PUT successfully creates one, then the origin server MUST inform the user agent by sending a 201 (Created) response. If the target resource does have a current representation and that representation is successfully modified in accordance with the state of the enclosed representation, then the origin server MUST send either a 200 (OK) or " -- https://tools.ietf.org/html/rfc7231#section-4.3.4

How do you signal to yada that the resource does not exist? There is an interceptor in the chain called yada.interceptors/get-properties. It pulls out the properties of the resource. You define this with {:properties (fn [ctx] {...})} in your resource map

yes I went ahead and try that, I was looking at interceptors as we speak 🙂

Set the exists? key to false, and the resource will be considered as not existing, causing a 201 rather than a 204

The only way to use yada effectively right now is to become somewhat familiar with the underlying code. It's not ideal, but until the documentation is more comprehensive it is the best way. HTTP is a huge surface to document properly

and the ctx in :properties will receive my response as well?

I mean, what I have in :response generates the body, but can I turn exists? off then?

You return a modified ctx in get-properties, that contains a :properties entry

kk

Yes - the get-properties call back is where you return resource metadata - if you need to go off to a database, you can return a promise, but what you return must be a modified context. Lots of these interceptors work this way, because your call back may want to access all the information and can change other parts of the context if it needs to

What you have in :response generates the body, yes, usually, but you can also return the (:response ctx) if you want more control

oh ok that's clear now

yada.methods is what ultimately dicates the semantics on a method by method level.

the trick to this part of yada is to realise that its up to the proxy function in yada.methods to interpret what you return in your :response function and to set the status and headers and body accordingly. Different methods in HTTP have different semantics - it's the yada.methods ns that encodes these semantics. You can also add your own methods of course.

@mark.melling: btw. Have you set raw-stream? to true? That's important. If you don't, uploads can be inconsistent.

@mark.melling: let me know if you don't know what I'm on about

yes I was checking that, it is kind of neat that you return just a map in :response though, not the whole context, I can go to the dbfrom :properties with a promise but then I need to coordinate the two methods (what if :response completes before :properties?)

in any case, I will try to get a better understanding by reading at yada.methods

oh, if you return a map, that's considered some data (useful in returning json). Be careful, maps are NOT Ring responses (unlike Liberator iirc), if you need to return a Ring response, return a (possibly modified) (:response ctx)

no well...I want to return a map that is then converted to JSON by yada...and so far returning it "as is" from the :response function was working

but maybe I am missing something 😄

FYI maps are considered data, not a ring-response by liberator. It used to be different, though, @malcolmsparks

@malcolmsparks: raw-stream? is set to true, as in http-server-components in dev/src/yada/dev/system.clj

when I do:

["workflows" {"" (resource-workflow-start db)
                                "/" {[:id "/"] (resource-workflow-update db)}}]

mmm it looks like it is not possible in bidi

ah found cool: :parameters {:path schema}

@ordnungswidrig: yes, thanks for correcting. My memory is confused. @richiardiandrea yes, in both liberator and yada returning a map is data. Gets coerced to json automatically