Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 4 years ago.
Improve this question
I want to go with Xamarin.Forms project. Now, I am bit confuse for consuming Rest API for this project. Performance matters.
There are many available but can any body please suggest me which should be best for Xamarin.Forms(.Net Standard)?
Microsoft Http Libraries or third party libraries like Refit, RESTSharp, PortableRest, etc.
Please suggest
All of these options are viable. I think the performance differences between these libraries will be marginal. So, it mostly comes down to what you feel comfortable with.
I like to use Refit because it will take a lot of redundant code out of your hands and you just have to focus on the contract. All the code for the actual calls is generated at compile-time (and thus won't impact your performance at runtime).
Also have a look at how well the library is maintained and if it's active. If you choose one that is already inactive for a while, chances are that you will start relying on older software versions which might not be what you want.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
I am studying the current architecture of uber rider app and I got to know the current rider app was evolved from MVC to a specific architecture called riblet, which is designed on top of viper by Uber themselves. As I understood riblets is independently testable pieces that each have a single purpose. I'm aware that the new architecture is capable of handling performance and scalability. I am interested in knowing the cons of riblet architecture.
Okey. I found some cons of the riblet architecture. I will post them here to discuss with anyone who is interested. The main cons are as follows,
Since there is a higher number of independent riblets communicating through their interfaces, there is a probability of failure of a particular interface compared to a system with fewer components.
Yes testing a single riblet is easy yet it makes integrations and handling the requests among riblets more complicated.
Changing the technology stack in the long run is difficult
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 6 years ago.
Improve this question
Did someone try developing a GraphQL instead of RESTful API? Can someone give real life (not only theoretical) pros and cons. Basically from my research I found that the GraphQL power is to get exactly what you need nothing more. Where with REST APIs, you often have to make a series of requests and you can easily get back more information than you really needed.
Is it worth the time spent on researching and learning GraphQL? Any bugs or showstoppers that get your attention?
This question is primarily opinion-based.
But from my experience:
Multiple requests on a RESTful-API for just one thing often indicates a lack in the API design, namely the needed resource was not available and therefore stuff needs to be gathered from different resources to compensate for this.
A REST-API that could be easily replaced by GraphQL indicates, that the API was in fact a CRUD-HTTP-API, what is considered an Anti-Pattern among REST-Evangelists.
Also worth noting is, that GraphQL puts responsibilty on the client, because the backing API is reduced to be a datastore that just needs to be queried. REST on the other hand enforces the behaviour of the client and therefore reduces responsibility on it. The client gets reduced to be something similar to a browser.
There are cases the one or the other approach would yield better results, but that greatly depends on your situation.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
Yes, while i'm working on node.js, i still love perl, :)
The old web product is based on old perl CGI, i'm looking to the simplest way to fix XSS/Sql injection/etc. web security holes, within a week including testing, :(
So for
Catalyst
Dancer
Mason
Maypole
Mojolicious
which one should i use in the ARM platform ?
Thank you !
You have fallen foul of the primarily opinion-based off-topic categorisation, and your question will probably be closed very soon. However I think it's worth offering a few guidelines here
First of all you should absorb what is written in CGI::Alternatives as it is a reasonable summary of the subject
Next you should separate the HTML generation functionality of your existing CGI code from the interface itself, and consider replacements for each of them separately. If you were to use HTML::Tiny together with CGI::Simple then your code would have to change very little and you would have achieved better partitioning of functionality
Ideally you will move on to one of the many templating systems such as Template Toolkit, together with one of the frameworks, which is the topic of your question. In the end you will need to do a lot of research and many trials to discover how well each framework fits your requirement, in terms of both the feature list and the convenience and clarity of the API
All I can do here is say that I am very fond of the Mojolicious suite and suggest that it may be a good starting point. The API focuses on command chaining in a way similar to Ruby, and there is a Mojolicious::Plugin::CGI accessory which will allow you to execute CGI scripts unchanged during your migration
Note however that all of the frameworks that you mention, as well as several others, will have their proponents. That is why you must make the selection yourself, as such recommendations will be influenced primarily by familiarity, and without your own knowledge of the requirements of your project
Unfortunately I cannot speak to the security issues of the various options, but I hope that has helped a little
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
I am starting to learn how to build rest Web service (I come from soap web service).
I'm an intermediate scala programer. I'd like to know as of now, what is the most widespread framework for building Restful Service. But i would also appreciate personal opinion on what is the easiest to use for the task of solely building rest api/web-service, very fast, with a not so complicate learning curve.
Many thanks,
-M-
Play, Scalatra and Spray are all good choices with a reasonable learning curve.
You'll have to look at these (and others), then decide which fits best with your own preferences. It's a very subjective question and there are too many variables for anyone to be able to give a definitive answer.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
I want to create a REST based chat application in Java using Eclipse, but I have no idea how to start. How do I take care of resources, verbs, and HEATOS.
Check out this link, or this link, or this link. I would personally recommend Jersey. restelt is very powerful, but might be quite complicated. RESTeasy has more features than jersey, but it can also be a pain to configure outside JBoss, and their community is not as 'active'. I would recommend Jersey, their startup tutorial is very easy to follow.
You can also look at this book, and this book. Sorry, I can't provide any hard answers as I have no knowledge, your level of expertise on the subject. Hope this helps.