I was actually doing something similar recently. I am not an expert
on web services or any of that, but I am using GET, with the
serialized message encoded as a URL-safe base64 variant (using '-'
instead of '+', and '_' instead of '/'). This makes it so that every
request can be represented as a URL. The response content contains
the (similarly encoded) serialized object that contains the result of
the request/command/operation/whatever. The only restriction that I
can think of is that some web servers may not like long URLs, but for
me, that is not an issue, since the encoded serialized messages are
never more than a few hundred bytes.
On Nov 25, 8:35 am, Michael Case <[EMAIL PROTECTED]> wrote:
> I'm trying to design a RESTful API using protocol buffers, which
> involves complicated searches with a lot of inputs.
> Searches, to me, should genereally be a GET. We're not updating
> anything, we're just running a query, basically. Now, simple searches
> are easily represented as a simple URL: myapp.com/employees/12345
> returns the record for employee #12345, right? But in my case there
> are a LOT of search parameters and filters specified, etc.., and its
> not very applicable to a URL. But its still just a query.
> Using protocol buffers, we have a search-request message that
> encapsulates all the inputs. I'd like to send that in lieu of the
> hairy URL, but GET doesn't (formally) support a request payload...
> I'm tempted to just use a POST, because its easy to send the request
> in the HTTP message body. But technically, I think this violates
> RESTful principals. I wonder if there are any recommendations that
> would allow me to be a purist?? :)
You received this message because you are subscribed to the Google Groups
"Protocol Buffers" group.
To post to this group, send email to email@example.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at