This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # admin-announcements (3)
- # beginners (26)
- # boot (12)
- # cider (1)
- # cljs-dev (13)
- # cljsjs (101)
- # cljsrn (5)
- # clojure (64)
- # clojure-android (1)
- # clojure-gamedev (1)
- # clojure-greece (23)
- # clojure-nl (9)
- # clojure-poland (2)
- # clojure-russia (3)
- # clojure-spec (11)
- # clojure-uk (159)
- # clojurescript (19)
- # component (1)
- # core-async (2)
- # cursive (2)
- # datascript (1)
- # datomic (2)
- # devcards (1)
- # events (1)
- # funcool (1)
- # hispano (1)
- # hoplon (24)
- # immutant (12)
- # jobs (1)
- # keechma (18)
- # lein-figwheel (2)
- # leiningen (2)
- # off-topic (8)
- # om (23)
- # onyx (4)
- # planck (26)
- # re-frame (149)
- # reagent (6)
- # ring-swagger (9)
- # spacemacs (1)
- # specter (33)
- # spirituality-ethics (11)
- # testing (10)
- # untangled (335)
- # utah-clojurians (3)
- # vim (3)
- # yada (46)
According to the “Responses” chapter in the manual, it looks like the answer is to manually construct the switch in the response function.
so it would be the client asking for one or the other and then what gets returned would be decided by yada during content negotiation
1. You declare the representations your resource can support 2. yada does the negotiation (proactively, reactive is on its way, not ready yet) 3. yada calls your response function with the results of the negotiation process contained in the ctx argument 4. You decide what to do - you can manually switch or you might return some data, in which case yada will try to automatically coerce if for you
So yes, it is manual, unless you rely on yada's automatic response coercion capabilities - and its protocol based so you can add your own
There are unfortunate knock-on effects to all that though, like if your two representations are JSON and XML, there’s no obvious intermediate data structure that can be encoded into a reasonable representation of both, so you end up having to write this switch in your 200, 404, 500, etc. handlers.
Typically they would return something different. It isn't idiomatic to return the same JSON/XML data for them as you would for a 200
I’m not too sure I understand, wouldn’t the content of the response be wildly different for 500 and 200?
I guess if you’re constrained to describing your result as a schema then probably you can’t actually use something like XML attributes?
I think that perhaps it might be best to simply have separate resource hierarchies, keeping resources simpler seems like the more manageable solution.
Yes, the content of a 200 response would be wildly different from a 500 one. So then I don't understand the question.
I was just pointing out that you’d likely have to repeat the same kind of logic (albeit slightly different) for each response handler
If there is an error, yada renegotiates the representation. So your 500 response can declare it only response with text/plain, while your 200 responds with XML and JSON
there's no obligation for your error responses to support the same media-types, etc. as your 200 response
That’s true but it’s a bit rude, for example I don’t think SOAP actually allows that.
The client is saying 'I'm happy with JSON, XML and text/plain', so it gets what it's asking for
If you client is saying 'I'm only happy with JSON', then yes, you have to support a JSON-formatted error
If the client says it’s happy with JSON and XML but not plain text then your 500 response that is only available in plaintext is invalid or what?
but mostly these will be similar for every resource in that case and you can weave them in to all your resources - this is the reason resources are described in data
Yes, if your error code can only produce plaintext, then you'd get a 406 situation in that case
I guess this would actually be specified in your API, so a request of that fashion would be a fault of the client’s.
I think a 500 without a message body would be the right thing to do, you shouldn't reasonably be able to recover from a 500
I think if you're writing a public API for general consumption you should try to support a reasonable number of media-types and should expect that clients know how to cope with plaintext as a fallback.
If it's an error and they insist on JSON only, just don't return anything besides the error code.
RFC 7231, Section 5.3.2 says that servers can reply with 406 (Not Acceptable) or disregard the Accept header and send whatever it wants. We typically use the
application/vnd.error+json media type for error messages, so we send that in the message body.
I can’t seem to find the part in the manual that explains how to capture path parameters.
I’m trying to match a path like
/notices/:domain, so I have a route like
[“/notices/“ [[“” global-notices] [“:domain” domain-notices]]]
If I visit
/notices/ then I see my global-notices resource, if I visit
/notices/arst then I get an exception:
java.lang.IllegalArgumentException: cannot treat nil as HTTP response for request to '’
If I change the route from
”domain”, then I can visit
/notices/domain (literally) and see the resource I was expecting, but obviously no path parameter is being captured.
Which is one thing I dislike about Compojure (matching methods) I wish the bidi author hadn't copied that
@jonathanj: this isn't going to excuse the bad error message but it's one that aleph emits when you return nil as a response, which is what is returned from the bidi matching process. I can't think of a reasonable way to avoid that error other than telling everyone to back stop their route structures with a catch all:
[true (yada/handler nil)]