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?? :)
> Thanks,
> -Michael-
You received this message because you are subscribed to the Google Groups 
"Protocol Buffers" group.
To post to this group, send email to protobuf@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 

Reply via email to