Are there any downsides to use directusSdk instead of making GraphQL requests?
According to documentation; My front-end can log in users and make requests through javascript SDK.
I would say using the SDK is a great option and is something I choose to do myself where possible, I believe that the Directus application uses it too, therefore it is well looked after 😌
Related
I built a web app in Laravel 5.2, and now, I would like to use Angular or Vue, so I am separating an API from my controllers.
Thing is actually, in my controllers, I use a lot :
Auth::user() to refer to the logged user.
What is the best way to deal with it???
Read books about API design. If the existing app isn't designed to be a RESTful API in the first place then you're in for a lot of learning. Laracasts has a great series called Incremental APIs.
Laracasts.com
Build APIs You Won't Hate
OK, I'm expanding my answer, despite this is not a great question, it is probably too broad. You need to look into Oauth 2.0 authentication for your API, you can still use a username and password, but OAuth 2.0 tokens over SSL is probably the best simple way to provide authentication for your API. If it is only used internally, or is read only then you may not really require authentication for the API at all. There's not enough information about your use case to even make a guess about that. Good luck!
I am new to web dev but I have managed to build my site using GWT and GAE. I use RequestFactory for client-server communications.
Now, someone wants to make mobile applications that use my backend.
I have found that RequestFactory works very well with Android. But I am somehow afraid it will not work with other "not-google" front ends (iOS for instance).
So my question is, can I make an API based on my RequestFactory backend (servlet) that can be used by any client? Any initial pointers as to how to implement it would be appreciated.
I guess technically it would be possible. However, if you want to create an api anyone can use, you probably want an api were you specify both how to communicate with the api and the content send/received by the api. With RequestFactory both the how and what is shielded by RequestFactory. So if someone wants to communicate with your api and can't use the RequestFactory code in the project, the how and what of RequestFactory must be reverse engineered, and could change anytime because it's not guaranteed. Not the most elegant way to go forward.
A better approach is define an open api were you specify the how and what. For example with
and apu based on REST (the how), communicating JSON data, and to specify the content format (the what). An example of such an api is the twitter api.
For your own project you could build on your api also, for example by using RestyGWT. Then you don't have to maintain both the code for the RequestFactory interface and REST interface. For other platforms there are probably several libraries available to make developing against a REST interface easy.
I have 2 different Rails application and I want these apps to send and receive information via an API. What is the correct way to do this?
I was trying to use this resource but I don't quite understand it: http://api.rubyonrails.org/
(I am not sure how to make the call for the different methods. Some methods show an URL which I guess I wouldn't have too much problem implementing, but what if the application is within the same server, what would be the correct way to call a corresponding API method.)
Is there a recommended beginners resource out there?
Thanks.
api.rubyonrails.org is Ruby on Rails documentation, so this is API of RoR. What you want is external HTTP, probably REST and probably JSON API.
There are many resources on building REST API's. In general you have to prepare some endpoints that application can send request to and handle responses.
Take a look i.e. on railscast about using active model serializers. This would be the part where you give other application endpoints to get or change data.
Normally you would stop here because in most cases you set API for other applications (like mobile or javascript applications). But in your case you will need something to send requests. There are many gems that allow that, but I find Faraday gem most useful.
So. I have embarked on the journey of learning Laravel in the last couple of weeks, and am thoroughly enjoying it.
It has come time for a site redesign and I thought it was about time to tighten up some of our functionality, so I am making the switch from CodeIgniter to Laravel.
I was wondering whether it is worth starting off with a RESTful API layer in Laravel (easy enough to create) and use it as a base even for the web application. In the future we are likely to build a mobile app that will need to use the API. So:
Is it worth having the web application connect to the API
and what is the easiest way/s to make calls to the API without having to write a bazillion
lines for cURL everytime I want to make a request?
It is definitely worth it.
I am currently redesigning a messy PHP code for an established hosting company turning it into beautiful Laravel code. I already have a mobile app working with it - Laravel makes it easy to return JSON data with one line -
Response::json('OK', 200);
or
Response::eloquent(Auth::user());
or
$tasks = Task::all();
Response::eloquent($tasks);
You don't need to use CURL as far as I know.
You can make all requests with simple AJAX, jQuery would simplify that.
Also using some MVC JS framework would help you make the application code structure more elegant for the client side, and the advantage is that you can easily package that into PhoneGap when you are ready to have your API take some real testing.
Today I posted on my blog about a simple example that you can try to see if this approach is worth your time : http://maxoffsky.com/code-blog/login-to-laravel-web-application-from-phonegap-or-backbone/
Check it out and accept the answer if you think it's on the right track.
As always, your results may vary, but this is exactly what I'm going through at the moment. I'm migrating a large .Net site with this API architecture and I've decided to keep it for Laravel.
I personally decided for this because:
More scalable. I can setup api.domain.com and then add additional
boxes/vm/whatever as our traffic grows. In fact, you could load
balance just the api by "round robin" or multiple dns entries for
that domain.
Future proofing for new sites and apps. Sounds like you're in the
same situation. I can see an app or two being added in the next year
or so.
Lost cost. You'll already be laying out your controllers, so really
it can be just a matter of setting them to RESTful and making small
tweaks to accommodate.
To be fair, some counter points:
Possibly additional load time, from processing through the API, though this should be minimal.
Additional security items to consider if you'd like to lock things down to just your app.
Either way, welcome to Laravel!
and what is the easiest way/s to make calls to the API without having to write a bazillion lines for cURL everytime I want to make a request?
#Sneaksta try postman chrome extension for calling rest services. you can create forms in this extension and pass data from these forms to you Rest services
https://chrome.google.com/webstore/detail/postman-rest-client/fdmmgilgnpjigdojojpjoooidkmcomcm?utm_source=chrome-ntp-icon
http://code.google.com/apis/libraries/devguide.html states that you need to sign up for an API to use the CDN. But why? You can clearly use it without.
Doesn't linking to google.com/blah/jquery.js?myAPIcode mean that a new version of jquery.js would be downloaded, rather than using a cached version? So using an API would slow down my website, and not using one would speed it up? Is there any advantage of using an API? Or is it just so Google can "contact you directly if we detect an issue with your site" AKA track you?
It says here a direct link is actually fastest:
"The preferred method is to load the libraries via standard tags (as in script src="https://ajax.googleapis.com/ajax/libs/jquery/1.4.2/jquery.min.js">, which will result in the fastest loads. "
Here it says a few reasons for using Load is that you can get the latest version automatically or specify a language or automatically load (or not load) css files, etc.
Given the http://html5boilerplate.com/ guys don't use an API, I think it's best not to. No one seems to know of a good reason. And Google tracking your site isn't a good reason (you probably use google analytics anyway!).