On Thu, Dec 10, 2009 at 07:56:49PM +0100, Romain François wrote:
> On 12/10/2009 06:31 PM, Pavel Shramov wrote:
> > On Thu, Dec 10, 2009 at 06:23:14PM +0100, Romain François wrote:
> >> What about then if you want to control the kind of output that is
> >> returned back (pb or json). I would then add&encoding=pb or
> >> &encoding=json. How do you do this ?
> > Everything is invented before us [1] :)
>
> Fair enough. I guess we could set Accept-encoding for that.
>
> > To be fair in my implementation I send response encoded as request.
> > Request encoding is read from Content-Type header and defaults to PB.
> >
> >> I don't have any strong opinions. I think the best format is :
> >>
> >> /base/url/{service}?method={method}
> >>
> >> where "service" is the service full name, and "method" the method name
> >> within the service.
> > So we have both URL and query encoding at once :)
>
> The rationale is this: it seems about right for a service to be bound to
> an url (whether the url uses the actual service full name or soime other
> key as per kenton's emails) and the method smells more like a parameter.
My 'design' was affected by SOAP (Web-Services) concept of port types -- one
service may implement different 'ports'.
For example (not real life but like it) you have arigmetic service which
consists of two ports: one of sum/substract functions and another of
mul/div ones. It's one service with one endpoint but implementing two
different sets of functions.
In my opinion URL (path without query part) is more similar to host:port
combination in raw transport (or endpoint int Web-Services terminology).
So xxx?method=method&service=service is more close to me.
> It is easy enough for me to encode the request in your format if I
> wanted to be able to interchange with your server, but is it not better
> to all use the same ...
It is so we'll trying to find common point...
As last resort we may define set of calling conventions for clients.
Pavel
--
You received this message because you are subscribed to the Google Groups
"Protocol Buffers" group.
To post to this group, send email to proto...@googlegroups.com.
To unsubscribe from this group, send email to
protobuf+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/protobuf?hl=en.
