OK, we’ll have to differ in opinion there. Call them REST, resource oriented, call them what you like, but REST style web interfaces over HTTP are just what you write nowadays. And it’s not just that it’s the only way of doing it over HTTP, there are very many advantages. And all of the REST APIs on the internet have “resources” that “do stuff”. I don’t see the conflict.
From: [email protected] [mailto:[email protected]] On Behalf Of Kevin Sapper Sent: 02 February 2016 10:26 To: ZeroMQ development list <[email protected]> Subject: Re: [zeromq-dev] XRAP clarification: What character set are strings passed in? 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]<mailto:[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]> [mailto:[email protected]<mailto:[email protected]>] On Behalf Of Kevin Sapper Sent: 02 February 2016 09:48 To: ZeroMQ development list <[email protected]<mailto:[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]<mailto:[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]<mailto:[email protected]> http://lists.zeromq.org/mailman/listinfo/zeromq-dev _______________________________________________ zeromq-dev mailing list [email protected]<mailto:[email protected]> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
_______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
