I'm a REST newb and having lots of trouble understanding how to use it, specifically, with the BAAS Kinvey & Javascript. I've spent quite a lot of time trying to learn how to use REST (which BTW is shockingly difficult to find) and the best resource I've found is this IBM paper.
Looking at the Kinvey website I found this 'guide', but it doesn't help me. I think it's because it assumes I'm experienced with consuming REST services. The guide provides details but no context. (This and this sort of help but it's just fragments ).
Again, there are various questions here on SO (here, here, here, here and here) but they are all either very specific or very general.
What I've love to see is something like:
What kind of [javascript] object to create (e.g. a XMLHttpRequest?)
How to construct a url request (build a query).
How the parts of request relate to the application (backend) I'm targeting.
How / where / if my credentials fit in.
How to handle the response.
Again, the guide on the Kinvey site is assuming too much of me, I don't know about Handshakes or Endpoints (sure I Google them, but without context it's hard to make the connection to how it works with Kinvey).
The 'try this' part of the Kinvey is also confusing. What is it doing and why does it break when I change applications, also, why / how is it connected to my account? Again, it's showing fragments and not a total example.
I would assume there'd be a simple, 15-20 lines gist showing a live example - or at least an example where it's explicitly explained where to drop in particulars.
I can figure it all out once I see a working example, I just need that complete example showing it end to end.
Side note: I'm using Angularjs; however, I'd like to know how I would do this in JS by hand, then I'll go back and learn how Angular abstracts it. If you happen to also know Angular, please add that example too.
Thanks guys.
I'll try to answer these one by one to the best of my abilities. I can't post more than two links without more rep, so just remove the 's' before my links to use them.
For http Requests via javascript it is important that you understand CORS
CORS tutorial
AJAX,
also it would be useful to check out
XmlHttpRequest
Reading the specification on rest is probably one of the best ways to get to know the fine details of what REST is and is capable of. Finding tutorials for using REST in programming largely depends on the language.
1: What kind of javascript object to create (e.g. a XMLHttpRequest?)
This depends on your browser and the version it is.
There are:
XMLHttpRequests found in IE7+, Firefox, chrome, safari ( Latest versions of these browsers supports CORS check here to see which ones.
XDomainRequests: found in IE 8 and IE 9 (supports CORS)
activeXObject: found in IE 6,7,8,9,10 (does not support CORS)
You can learn more about IE specific objects using microsoft's msdn api reference. Usually a quick google will have good results for these objects.
2: How to construct a url request (build a query)
Assuming this is for javascript building the request depends on the server you are sending it to. I have already linked you to several links that help you build the http request and send it. If you want to see an actual implementation that is in practice now, you can check out :
the request function in apigee's usergrid.js
at line 67( at the time I posted this),
If you want to see how to build the query string( the '?' after the URI) check the encodeParams function in that link. Note there are many ways to do this. This is just one. You could easily just append the "param=value" on by on on to the "uri" + '?'
Something to note is that the Apigee example is not Cross Browser Compatibly. It just assumes XMLHttpRequest Version 2 which not all versions of browsers support.
3: How the parts of request relate to the application (backend) I'm targeting.
If you are targeting kinvey that RESTful api link you provided is really the best way to explain it. It details what your url and http request headers should look like for the actions you are trying to take. The guides Kinvey has for rest have more specific examples for an http request.
The components that go in to the URL largely depend on the backend. If you have a more specific question I can try to answer that.
4: How / where / if my credentials fit in
This again depends on the backend/server. For Kinvey they use Basic Auth and OAuth.
You should check out their guides on security for more info about that.
If you studied/researched the initial links I posted and learned about http requests then your credentials would go under the Authorization header of the httpRequest. For kinvey it usually goes like this:
Authorization: "Basic " + Base64encoding[appId:appSecret] or "Kinvey " + [authToken]
5: How to handle the response.
Again depends on the backend/server.
The aforementioned links on AJAX and CORS tutorial show you how to handle the response.
There are many different responses you can get, xml, json, simple text etc. The type you want is usually specified in the request header's accept field by You or by the server's response header's content-type which tells you what type it sent back or can send back, but that requires calling to the server once to see what it sends by default. Many mBaaS usually specify the responses in their documentation
For kinvey, they usually send back JSON so you can just use JSON.parse() the response and access the data you need from the JSON object.
Hopefully that answered some or all of your questions and if anyone thinks I did something wrong or said something horribly inaccurate let me know. This is my first time posting on stack overflow, but I have used kinvey as well as many other mBaaSes for my work. So I got to know them a little.
Finally, if you learned what you wanted to, just use Kinvey's javascript api which will handle all the interactions with RESt for you. No need to reinvent the wheel unless you need to do something more specific that JS frameworks don't provide.
Related
I'm not an experienced web developer so I'm having some issues connecting some dots with regards to ClickUp API (In my case) but it can be probably be more generalized as well.
I've been doing a bit of research, but can't seem to get exactly what I'm looking for which makes me think I'm missing something.
In my case, the goal is to make certian information on ClickUp publicly VEIWABLE (not writable) and format the html/css ourselves. This would be veiwable to strangers without requiring authentication with ClickUp in any way.
ClickUp provides public links and embedd options:
My attempt(JS): postMessage(content, url) and document.getElementById(frameID)
Issue: These will fail in browsers that enable that cross-origin protection thing. Forcing strangers to disable this security is not viable for us. I've also tried alloworigin, anyorigin, etc with no luck.
ClickUp API 2.0 for POST, GET, etc
Attempt: I wanted to use this unofficial JS wrapper https://www.npmjs.com/package/clickup.js but didn't write anything out yet.
Issues: From my understanding, this requires the stranger to authenticate with ClickUp before being able to read information. This would require server-side code.
Other issues: This read-only page is intended to be hosted on github which doesn't support server-side calls (from my understanding) so the solution I'm looking for may not exist.
The most straight-forward way I can think to solve this is the parsing embedded iframe method but the cross-origin problems kills it dead in the water. At this point, I'm stuck and would appreciate any additional feedback.
To formalize my question:
What architecture/pieces would I need to connect a front-end web page with private ClickUp information in a read-only fashion that allows front-end HTML/CSS modifications without user authentication?
My web development knowledge doesn't really go beyond javascript and maybe a tiny bit of PHP so if there's other tools available for this please let me know and I'll look into them.
Thanks for the time
I'm developing a Webapp that uses Angular.js which server by a RESTful API. During the development phase I use my preferred browser which is Chrome, but I just ran some tests in Edge and made some interesting discoveries.
I noticed that the result of a call to the RESTful server was seemingly returning incorrect data. Upon closer inspection I realised that this was due to the Edge browser loading the results from Cache rather than making the call to get the latest and correct results. What's more I realised that I can remove whole functions from my Angular app file and Edge doesn't seem to complain!
The angular function in question:
$http.get(frontbaseurl+'/users/auth_user.json').then(function(response){})
I've read a few responses to questions on SO that suggest various ways to force Edge to not cache results (for example adding a data stamp to the get url), but it sounds hacky and in my case it didn't work anyway.
I can't quite believe my findings. The coder in me wants to shrug my shoulders and put this down to yet another catastrophe from MS, but I can't ignore the fact some unfortunate individuals may have no other choice and could experience errors if they use my web app.
Anyone else experienced this?
As a web developer, I really appreciate that browsers put heavy cache to avoid unnecessary requests to my server and help my users to have a faster, and better, experience.
There are many techniques to request the browser to stop caching, but please, don't do that! Caching is very helpful and there are smart ways to prevent the browser to use old content.
I've read a few responses to questions on SO that suggest various ways
to force Edge to not cache results (for example adding a data stamp to
the get url), but it sounds hacky and in my case it didn't work
anyway.
I believe that you missed the point here. You don't add the a data stamp to the get url. You need to add it to the file url.
Wrong:
$http.get(frontbaseurl+'/users/auth_user.json?v=20160510').then(function(response){})
Right:
<script src="/path/to/services.min.js?v=20160510"></script>
Adding the querystring to the file name should be part of your build action.
Perhaps try this:
$http.get(frontbaseurl+'/users/auth_user.json?' +some random number).then(function(response){})
the random number must change in every call
or
$http.get(frontbaseurl+'/users/auth_user.json?' ,{cache:false}).then(function(response){})
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 8 years ago.
Improve this question
instead of doing all your server operations via the POST method token ( and the content type set to json ).
I've done some research here and I am referring to the method tokens mentioned in the ietf document.
https://www.rfc-editor.org/rfc/rfc2616#section-5.1.1
https://developer.mozilla.org/en-US/docs/Web/API/XMLHttpRequest
I don't see the benefit of using all the other server type requests. I know they are used, particularly what spurned this interest was Backbone's use as seen here:
var methodMap = {
'create': 'POST',
'update': 'PUT',
'patch': 'PATCH',
'delete': 'DELETE',
'read': 'GET'
};
These properties are eventually passed to the xhr open method which you can read about in the links I posted above.
Actually the MDN article has pretty much no information while the W3 articles seems a bit esoteric.
What you've described is an application design philosophy called Representational State Transfer (REST). The philosophy is much more encompassing than just using multiple request methods. It also covers the idea that each type of data needs its own URL, how that URL should be logically structured and what should belong to query parameters and what should be a URL path. REST is one of the earliest ideas related to Semantic Web - the idea that websites should be easily readable to machines as it is to humans (or to put it another way, the idea that the website should be easily understandable to developers as it is to regular users).
You can read the original paper describing REST here: http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm
REST is actually just one chapter in the whole paper. The paper describes what a web architecture should ideally look like.
Do you need REST?
The short answer is of course no. Technically speaking you're allowed to do whatever you want that works. Indeed, back when ideas of REST was first introduced there were no easy way to do PUT and DELETE requests on some browsers. So people stuck to GET and POST and the HTTP spec was updated specifically to make GET and POST have RESTful meaning.
The HTTP specification recommends that GET only be used for indempotent operations (requests with no side effect) while POST should be used whenever a request causes something to change in the server. But developers have been using GET to update databases due to easy debugging because you can just construct the query in the URL entry field in your browser. The RESTful way is to only allow POST requests to update the database (or save anything to file).
What's the advantage?
The advantage is to essentially allow developers to treat the web as an API. Allowing machines to read webpages allows for things like mashups, creating mobile apps as front-ends etc.
A good API or library is consistent. A consistent API is easier to use, easier to remember and doesn't require the developer to look-up documentation too often. REST attempts to provide this consistency by giving real meaning to the types of request. Therefore if you see PUT request you don't have to guess what it's doing.
As such, as a programmer, it is to your advantage to not only be RESTful as much as possible but also convince as many other programmers as possible to create RESTful websites. If all websites are RESTful, writing scripts to do smart things with online data becomes much easier.
On the other hand, as a programmer, you also have the freedom to disagree with other people's ideas.
I did a lot of google searching and none of the explanations give a really basic easy to understand explanation so I'm hoping someone here can really help me understand this.
For this question I'm going to use a project I'm working on written in Javascript. Say I have some code that's going to go into an API and pull data on a toy. The toy has several properties such as price, number of parts, colors, stores sold in, manufacturing date, etc.
I make a request to get the data from the url where this data is stored, say "myapi.com/toy/search?query?=" + toy.
What is the API doing there? What is it storing? Is it storing the data on each individual toy? Or is it just a template of what data the toy SHOULD have and then the data for each toy is stored else where?
Thanks, I'm very new to this so if you see key flaws in my question itself I'd appreciate corrections and clarifications there as well.
Any API has its own set of rules, and you're going to need to consult the specific documentation for the API you're going to use to find out exactly what data it exposes to you and in what formats.
You're misunderstanding what's meant when it's stated than an API is a set of rules. It's not to say that there's a set of rules which a system has to meet to be considered an API.
Rather, the developer of an API provides its users with documentation explaining what one should expect when interacting with their API. That documentation provides you with an understanding of the rules which you must follow to correctly use that particular API.
In short: I could write an API associated with any kind of data I want, and I could store that data wherever I want, and move it around in any format I want.
It's the creation of a set of rules that say "This is the result I promise to serve up in this specific format when you request it in this specific manner" that makes an API.
In your case, your are using the API to connect the client application (your javascript code) to the server application (where the data resides).
The server exposes a simple interface (Application Programming Interface) for any client to request an action to be executed on its behalf.
It depends on the context of the API. You are speaking about a REST API. A REST API uses the concept of resources. You should dig deeper into this particular API topic: RESTful APIs.
But APIs have different contexts. Maybe it helps to read about my journey where I experienced these different contexts as concrete examples of APIs. These concrete confrontations put together the bigger picture about APIs for me.
Does anyone know how disqus works?
It manages comments on a blog, but the comments are all held on third-party site. Seems like a neat use of cross-site communication.
The general pattern used is JSONP
Its actually implemented in a fairly sophisticated way (at least on the jQuery site) ... they defer the loading of the disqus.js and thread.js files until the user scrolls to the comment section.
The thread.js file contains json content for the comments, which are rendered into the page after its loaded.
You have three options when adding Disqus commenting to a site:
Use one of the many integrated solutions (WordPress, Blogger, Tumblr, etc. are supported)
Use the universal JavaScript code
Write your own code to communicate with the Disqus API
The main advantage of the integrated solutions is that they're easy to set up. In the case of WordPress, for example, it's as easy as activating a plug-in.
Having the ability to communicate with the API directly is very useful, and offers two advantages over the other options. First, it gives you as the developer complete control over the markup. Secondly, you're able to process comments server-side, which may be preferable.
Looks like that using easyXDM library, which uses the best available way for current browser to communicate with other site.
Quoting Anton Kovalyov's (former engineer at Disqus) answer to the same question on a different site that was really helpful to me:
Disqus is a third-party JavaScript application that runs in your browser and injects itself on publishers' websites. These publishers need to install a small snippet of JavaScript code that makes the first request to our servers and loads initial JavaScript loader. This loader then creates all necessary iframe elements, gets the data from our servers, renders templates and injects the result into some element on the page.
As you can probably guess there are quite a few different technologies supporting what seems like a simple operation. On the back-end you have to run and scale a gigantic web application that serves millions of requests (mostly read). We use Python, Django, PostgreSQL and Redis (for our realtime service).
On the front-end you have to minimize your payload, make sure your app is super fast and that it doesn't break in extremely hostile environments (you will be surprised how screwed up publisher websites can be). Cross-domain communication—ability to send messages from hosting website to your servers—can be tricky as well.
Unfortunately, it is impossible to explain how everything works in a comment on Quora, or even in an article. So if you're interested in the back-end side of Disqus just learn how to write, run and operate highly-scalable websites and you'll be golden. And if you're interested in the front-end side, Ben Vinegar and myself (both front-end engineers at Disqus) wrote a book on the topic called Third-party JavaScript (http://thirdpartyjs.com/).
I'm planning to read the book he mentioned, I guess it will be quite helpful.
Here's also a link to the official answer to this question on the Disqus site.
short answer? AJAX, you get your own url eg "site.com/?comments=ID" included via javascript... but with real time updates like that you would need a polling server.
I think they keep the content on their site and your site will only send & receive the data to/from disqus. Now I wonder what happens if you decide that you want to bring your commenting in house without losing all existing comments!. How easy would you get to your data I wonder? They claim that the data belongs to you, but they have the control over it, and there is not much explanation on their site about this.
I'm always leaving comment in disqus platform. Sometimes, comment seems to be removed once you refreshed it and sometimes it's not. I think the one that was removed are held for moderation without saying it.