What you're trying to do is implement RPC over REST which is a conflict of interest. So using a resource oriented protocol like XRAP probably wont work well for your use case.
2016-02-02 11:04 GMT+01:00 Tom Quarendon <[email protected]>: > With regard to parameter values, I’m treating XRAP as much more general. > So in the same way that I might design a fairly general web service that, > say, converted miles to kilometres, and expose it as a “REST” service as > > GET /api/convert_m_to_k?miles=1 > > I’m doing the same, just using XRAP. Seems reasonable to me. So my > parameters could be anything. > > > > *From:* [email protected] [mailto: > [email protected]] *On Behalf Of *Kevin Sapper > *Sent:* 02 February 2016 09:48 > *To:* ZeroMQ development list <[email protected]> > *Subject:* Re: [zeromq-dev] XRAP clarification: What character set are > strings passed in? > > > > The only reasonable choice for encoding is indeed UTF8, thus I agree to > explicitly state this in the spec. > > As far as parameter values are concerned allowing binary content seems > fine to me. But keep in mind that they should only be used for sorting, > filtering or paging a collection of resources. > > If you like to edit the spec checkout the github project > https://github.com/zeromq/rfc and send a PR. > > //Kevin > > > > 2016-02-02 10:21 GMT+01:00 Tom Quarendon <[email protected]>: > > When attempting to implement an XRAP client in java, one of the first > issues you come across is what character set should strings be passed in in > the XRAP messages. > > So the client needs to build a GET message, and it needs to put the > resource name in it. The resource name is a string, so is naturally > represented in Java as a String object, in Unicode. > > I’ve assumed that things that are naturally strings (resource names, > content types, parameter names, metadata names, error strings) are actually > passed in UTF8, but this isn’t specified. > > > > I think the specification needs to be explicit about what character set > strings are passed in, and indeed which things are actually “strings” in > that sense. I think it’s clear that the resource names, content types, > parameter names, metadata names, error strings are actually intended as > human readable strings. However, it gets a but greyer with > parameter/metadata values, etag values and content bodies. > > For the body, you have to take into account the content type, but even for > those content types that are textual (JSON, XML) currently you just have to > assume that the encoding is UTF8 (I don’t **think** that is explicitly > defined by application/json, but perhaps it is, in which case fine). > However the body won’t always be textual, in the music example in the spec, > actually retrieving the music track would most likely return binary data (I > don’t think it would return a JSON with a BASE64/85 encoded piece of binary > data in it would it?). So you can’t always assume that the content body is > UTF8 text I don’t think. > > Etags are supposed to be opaque to the user, but it’s not clear whether > this has to be opaque textual data, or whether this can be binary data. > Maybe this is clearer in HTTP, since it’s passed in an HTTP header value, > which are always ASCII anyway. I think this needs clarification in the case > of XRAP, as there’s no particular reason it couldn’t be opaque binary data. > > > > Ditto parameter values. I can imagine sending binary valued parameters. > Indeed I am. Clearly these could be expressed as BASE64 or BASE85 encoded > values and hence text, at some slight cost, but I think this needs > clarification too. > > > > Assuming there is some consensus, can the spec be edited to reflect? > > Thanks. > > > _______________________________________________ > zeromq-dev mailing list > [email protected] > http://lists.zeromq.org/mailman/listinfo/zeromq-dev > > > > _______________________________________________ > zeromq-dev mailing list > [email protected] > http://lists.zeromq.org/mailman/listinfo/zeromq-dev > >
_______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
