I'm not suggesting you do the following, there are clearly a lot of issues that would come with it. However I'm just trying to make an analogy to show you how convoluted what you are doing is: you could just have users upload an IDL file instead to achieve the same end, your service would then be able to handle whatever kinds of data types your users wanted. You're recreating the purpose thrift serves in IDL, the whole concept is confusing and probably isn't going to help people readily adopt your api. On Apr 12, 2013 12:05 AM, "Avinash Dongre" <[email protected]> wrote:
> Hi, > Thanks for your comments. > My product is Key-Value store . Which has api like put(Key,Value) > We have done all sort of stuff to make sure that we can handle C#, C++ and > Java object directly. What I was thinking to make it work with thrift. > So that If I am python developer, I can put my python objects using the put > api. > > Thanks > Avinash > > > > On Fri, Apr 12, 2013 at 1:36 AM, Will Pierce <[email protected]> wrote: > > > I don't know anything about your API but in my personal experience, I > tend > > to prefer APIs where every element is well-named and meaningful. It > > provides a stronger contract from server to client about the commitment > (or > > contract) to provide data in a certain way. I most enjoy APIs that have > > strong internal-consistency for naming conventions and defaults, and > also a > > lot of self-similarity so the outputs of one method are easily used as > > inputs to another. > > > > You can define all sorts of generic container objects that will cover > every > > expected use-case, but you might want to think about the relative > > importance of flexibility vs. clarity of structure and simplicity, always > > remembering that flexibility is more expensive (for both sides of an RPC) > > in terms of code complexity needed to handle the various permutations in > > which a generic container type might manifest itself. > > > > I'm really guessing at your use-case here, though. Can you share some > > more detail? > > >
