2009/12/10 Romain François <[email protected]> > Cool. Do you have your layout documented somewhere in your project. > > Embed service full name and method name in the http request as we do allows > the request to be self-contained. What kenton suggests needs the client to > know of the mapping between the service full name (in pb speech) and the > http service name, which might then need an independant exchange before hand > between the client and the server . >
No, that's not what I'm suggesting. The client doesn't start from "I want to use FooService.". The client starts from "I want to talk to http://example.com/foo-service, which I already know is of type FooService.". It doesn't make sense for the client to ask the server where to find a FooService, because the server might expose *multiple* FooServices. The client has to know which one it wants to talk to. The URL identifies that. > > client: how do you call this service > server: foo > client: sending the http request using foo > > Either way is fine. It would be good to all agree on what rpc over http > means. > > > On 12/10/2009 10:15 AM, Marc Gravell wrote: > >> >> The layout in the original post looks a lot like how protobuf-net does >> RPC over http. It uses {root}/service/method, but it would be trivial to >> tweak it to use any similar pattern. I'd be happy to make tweaks to >> protobuf-net to make it play the same game, and try a few >> cross-implementation scenarios. >> >> Marc >> >> 2009/12/10 Romain François <[email protected] >> <mailto:[email protected]>> >> >> >> On 12/09/2009 09:12 PM, Kenton Varda wrote: >> > Coincidentally, last weekend I started working on an open source >> > protobuf-based RPC system. Currently I am defining a socket-level >> > protocol, but I also intend to support an HTTP-level protocol with >> > optional JSON encoding to allow calls from Javascript. I stuck some >> > totally undocumented code here: >> >> Thanks. My intention of having it over http is that it can communicate >> with other languages. I'd be good if we can synchronize our protocols. >> >> I need to make some changes based on what you said on another thread, >> and then I'll make my java basic server code available. >> >> > http://pbcap.googlecode.com >> > >> > But some coworkers pointed out that the name is confusingly >> similar to >> > "pcap", so I'm planning to change it. >> > >> > Currently this is not an official Google project; I'm working on >> it in >> > my spare time. >> > >> > 2009/12/9 Romain François <[email protected] >> <mailto:[email protected]> >> > <mailto:[email protected] <mailto:[email protected]>>> >> >> > >> > A request looks like this : >> > >> > ----------------------------------------------------- >> > POST /{service full name}/{method name} HTTP/1.0 >> > >> > >> > I would recommend against putting the service type name in the URL. >> > This makes it impossible to export two services of the same type. >> > Instead, you should allow the application to register services >> under >> > any name it chooses. >> >> Fair enough. Maybe adding some protobuf specific headers : >> >> ProtobufService: {service full name} >> ProtobufMethod: {method full name} >> >> or encode it as parameters of the url as you said. >> >> > I'd also suggest making the method name be part of the query, like: >> > >> > POST /someservice?method={method name} >> > >> > This may be a matter of taste, but I feel like a service object >> should >> > be a single HTTP "resource", rather than have each method be a >> separate >> > resource. >> > >> > Connection: close >> > >> > >> > Why not allow pipelining? >> >> this was simpler to do a one shot service call, but indeed why not. >> >> > Content-Length: {length of the serialized message} >> > >> > {raw bytes of the serialized message} >> > ----------------------------------------------------- >> > >> > And a successful response looks like this: >> > >> > ----------------------------------------------------- >> > HTTP/1.1 200 OK >> > Content-length: {length of the serialized response} >> > >> > {raw bytes of the serialized response} >> > ----------------------------------------------------- >> > >> > Since this is very early in this, I wondered if others would >> have views >> > on this. >> > >> > http is quite verbose for sending protobuf message around, >> but it is >> > likely to be implemented for a lot of languages. >> > >> > Regards, >> > >> > Romain >> >> > > -- > Romain Francois > Professional R Enthusiast > +33(0) 6 28 91 30 30 > http://romainfrancois.blog.free.fr > |- http://tr.im/Gq7i : ohloh > |- http://tr.im/FtUu : new package : highlight > `- http://tr.im/EAD5 : LondonR slides > > -- You received this message because you are subscribed to the Google Groups "Protocol Buffers" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/protobuf?hl=en.
