I am trying to refactor some services with grpc json transcoding but have problems with understanding how to do some things. If anyone has some good documentation or tutorial it would be great.
Is it possible to make something like this
rpc Search (string) returns (SearchResponse) {}
or all parameters must be actually a message?
or all parameters must be actually a message?
Yes, basically
I have plans to simplify that in protobuf-net.Grpc (so that the machinery hides all that from you), but: that isn't the case today.
Related
I'm new to Elixir, and functional programming in general really, and I'm looking for a little guidance on whether it's the 'right' thing to do to to build struct models of data contracts in an SDK I'm building for the Xero API.
The gist of the SDK is that it exposes the endpoints - and operations on those endpoints - of the Xero API, performs OAuth1.0a authorisation, and then makes web requests to the API. What should my SDK be returning to the consumer?
Should I
just return the raw HTTPoison response and leave it up to the consumer to handle?
use Poison to deserialize the returned JSON payload into a map and return that?
create structs for each of the data contracts and use Poison to decode the JSON string into those structs with a little brute force?
Is there some other more correct way to do this in Elixir/functional programming?
The API also supports PUT/POST operations and so if using structs, the structs can be supplied to these operations and encoded down to a JSON string.
The data contracts in the API are pretty complex with a quite a bit of nesting.
You can see an example of one in the documentation
This is the SDK repo for anyone interested
If you are asking whether you should transform requests payload into Structs as soon as they reach you, then answer is yes. Structs are bare maps underneath but they only use :atoms as keys which means they fetch faster.
It is also easier to read for fellow programmers that may maintain your code later. I also suggest reading this article.
I have done some R&D on above libraries and have used some in my project.I am using Moshi for json parsing, OkHttp3 library for http connections and Rxjava for asynchronous and event based programming in my project. Now when I looked at retrofit, I felt its of no use as I have already used above main components of retrofit myself.
Just want to know the ideas of the people whether I am thinking in right direction or not.
Edit: From my point of view, Retrofit only provides clean interface of http client where one can customize requests,headers etc with annotations.
This is a good choice of libraries from my point of view. The first three are developed by Square and they work very well together. However the main difference is that each library works on a different layer.
OkHttp: transport layer. Deals with http protocol. Performs networking.
Moshi: Json parser. Transforms bytes from OkHttp into a Java objects.
Retrofit: Rest layer. Transforms HTTP logic (status codes), into REST logic.
RxJava: provides tools to create reactive code, instead of imperative code.
Lets say I am building a web service that is returning a random number?
Real world example: http://www.random.org/integers/?num=10&min=1&max=6&col=1&base=10&format=plain&rnd=new
random.org does this via GET method, which is not RESTful I think. Specs are saying that GET method should be idempotent.
What method would you suggest and what would your URL be?
There is no problem here. Being idempotent has nothing to do with returning the same thing all the time.
When you are using another web applications Restful API, do you usually use a wrapper library or do you use the Restful API directly with a HTTP client?
This is a hard question to answer, primarily because in the current state of the industry, the right answer is very impractical.
The correct answer, in my opinion, is you should not use a wrapper API. The uniform interface is HTTP and that should be the programming model the client works against.
Having said that, there is nothing wrong with having helper classes that parse media types to generate strongly typed versions. Something like this,
var response = HttpClient.Get(linkTofoo);
if (response.ContentType =='application/foo') {
var strongFoo = FooHelper.Parse(fooResponse);
HandleFoo(strongFoo);
}
Unfortunately, a vast majority of apis that claim to be RESTful, are not. They do not respect the self-description and hypermedia constraints and therefore they make it very difficult to interact with them in a RESTful way. They require you to do client side URI construction and have prior knowledge of the types that will be returned from endpoints.
The sad fact is that with many APIs you have little choice but to use a provided client proxy library. This should not be the case.
If you are looking for evaluating a client library, just make sure it is a stateless one. The client library should not start managing the lifetimes of the returned objects. Http caching does that, so unless it is an uber-smart library that can invalidate object references when the cached representation expires, avoid any stateful client libraries.
e.g.
var foo = remotelibrary.GetFoo(233);
var bar = foo.bar; // If this causes an HTTP request
var barcopy2 = foo.bar // and this doesn't because it already has a reference to bar
// I would be very leary of using this library
It is almost certainly going to be better in the long run to use a library. This allows you to abstract away the restful-ness of the design and ignore the whole HTTP business.
If there is not an existing library for whatever API you're using then you should consider writing your own.
Instead of using the web services infrastructure provided by .net, I was wondering what your take on rolling my own asp.net page that you can post data to (I guess all the cool kids are calling this REST,) and retrieving a JSON response from. Is there additional overhead in using an aspx page for this purpose that i'm not aware of?
Yes and no. You can use ASP.NET, even without MVC, to handle this rather effectively. But you probably don't want to use pages. Rather, you should implement IHttpHandlers for your rest actions.
As for handling the JSON angle, check out JSON.NET if you don't want to use the baked-in WCF/Scripting stuff.
Even if you'd use existent helper classes, you'd have to implement your own message parsing (including error handling etc.) and thus lose transport transparency (would require more effort to switch to other protocols/formats) unless you implement a communication infrastructure similar to WCF's. And then you might need additional features such as security..... just use WCF if you can ;)