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.
Related
I want to fetch my Google Analytics report to my local through an api.
I have created a Report in Google Analytics explore : this image.
Here I can download the csv which I want to read the data in my local through the csv.
Now for that I am trying to follow this document :
Quick Start
Which I am not sure this is correct approach or not. Also got stuck on some point like
I have downloaded Credentials.json where not sure what to change in client_email.
What is the best approach to achieve that. Any programming language is fine. Can anybody help me here to achieve this.
That api you're using is called the Reporting API or the Data API as they've remarketed it for GA4. And generally, it would be a good practice to use it and there are plenty of libraries and examples of its usage in multiple languages, including Python, here is a good example. I'd suggest either going with a third party article detailling the setup process, or even just using a third party library that can abstract a lot of roughness Google introduced in the API.
But that api is new, and the product, overall, is effectively just a beta with quite a number of bugs and documentation holes. There's a simpler way to get the data out. First, link the GA4 property to BQ. This will effectively set up daily (or streaming) exports to BQ.
Once the data is in BQ, you're able to see the raw data and understand it way better than in GA4 explorer. From there, it will be much easier for you to export the data to your local from BQ. Here is a library that could be handy. Having the raw data in BQ makes it way easier to debug your data reports.
I'm working on an Angular 4 front-end for an API built by another team. The API follows HATEOAS and provides me with hypermedia links with every single response.
I know the shape of the API and I figure I can just hard-code the URLs into Angular Services with minimal fuss. However, a colleague (who is a backend developer) is trying to convince me that I should take full advantage of the hypermedia because it will mean less coupling between the frontend and backend (and potential breakage if the API changes).
However, I'm stumped on how I'd even go about implementing a simple HATEOAS pattern using Angular's built-in Http service. How would I store/share the hypermedia/URL information in a way that doesn't couple all the services together and make them hard-to-test? There seems to be no examples out there.
Would trying to create a HATEOAS-friendly HTTP client even be a good idea, or is it likely not worth the trouble?
Your colleague is right, you should use the meta information that the back-end provides. In this way you are not putting responsibility on the client that doesn't belong there. Why should the client know from where to fetch the entities? Storing the entities (in fact the data in general) is the responsibility of the back-end. The back-end owns the data, it decides where to put it, how to access it, when to change the location or the persistence type, anything related to storing the data.
How would I store/share the hypermedia/URL information in a way that doesn't couple all the services together and make them hard-to-test?
Why do you think using HATEOAS makes the testing harder? It does not, in fact not using it makes the testing harder as the URLs are static which makes the back-end non-stub-able.
You can extract the information from the back-end response and store it as meta-information in the angular model, on a _meta key or something like that.
I'm trying to understand API's.
Question1:
I get it that it helps two applications to talk with each other. So if I were to use a third party service in my application, I can do that by using their API. Understood. But why would we need API within a same company ? If suppose XYZ company has a java/ js application and they get the data using the companies internal API. What's the point of having an API when the resource is within the same company.
Also, should this be a REST or SOAP?
Question2:
Suppose I have users using my API "x1" which has underlying database "d1" which has a schema "s1". Now, I have completely changed the underlying database & schema to "d2" and "s2" and have a new API "x2" . How can the users still continue to use my API without knowing this transition? How can the transition be done transparently without the users knowing this.
Question3:
Also what does it exactly mean by "rest can be cached? " . Any example ?
There are just two types of API's ? REST & SOAP right?
I was asked these questions by someone & I'm totally got messed up. Can someone explain and clear my confusion?
At its simplest, an API is a set of reusable functions for accomplishing a particular task. So if you write a C program using the standard fopen function, you are using the POSIX API, which defines how that function should behave. Crucially, your program doesn't need to know how the function is implemented, because the API is an abstraction for doing the same task on different systems. The particular implementation will be provided by a library on each target system.
This kind of direct API only works if you are using the same computer, and your program and library are written in languages that can be easily bound together. In some cases, you need to bind more varied resources together, so need a different kind of API. For instance, you might write a script-friendly command-line interface to your library (a text-based API), or use signals and pipes to communicate between two running processes (called IPC, for Inter-Process Communication).
This brings us to networked APIs, and in particular Web APIs, which were the main subject of your question. These are just the same as the above, but they use HTTP and related technologies to let processes talk to each other even if they're not on the same host. As you say, this allows an organisation to have a public API, but it also allows a system to be scaled onto multiple servers, using multiple programming languages and technologies. The notion of abstraction means that a section of the system provided as an API service can theoretically be competely replaced by a new implementation without any changes to the programs consuming it. If a redesign is needed, it may be possible to provide a wrapper which looks like the old API, and calls into the new one, translating data as required.
There are many ways to build a Web API, but they broadly fall into two categories:
RPC (Remote Procedure Call) APIs are based around actions, or verbs, with defined parameters, effects, and return values; it as though you are calling a function or procedure on a remote host. SOAP is a particular standard for RPC-style APIs, which defines an "envelope" using XML; it doesn't define much within the envelope, though.
Resource-oriented APIs focus on nouns rather than verbs, and don't aim to resemble a classic function call. You could consider an RSS feed a simple API of this kind - accessing the URL for the feed causes the server to generate the resource, and present it in a well-defined format for some other program to consume. REST is a formalisation of this idea, using URLs to represent objects, and HTTP requests to represent actions on those objects - GET to retrieve, POST to create, PUT to update, etc. By using HTTP, the idea is to make use of existing techniques used for human-readable resources, such as cached responses, without the user needing to know how the API is written.
Since these APIs are supposed to be language neutral, it is necessary to define how the data is represented; the most common formats are XML and JSON, but there can be others, such as Google's Protocol Buffers.
I'm looking for help deconstructing the MEGA (mega.co.nz) login process for use within a purely GET/POST context. I can't make sense of the documentation because the majority of it is wrapped in the C++ SDK, which I don't understand. The "Under the Hood" section of the documentation has a variety of URLs and their parameters but it doesn't tell me how make a login request.
So, can anyone help me to find the following info:
The URL and parameters to make a login request
The process for decrypting the returned session tokens
I think that with the above info I can work with the API without having to mess with the client SDK.
I added the JavaScript and Objective-C tags because I can read these languages and they are popular.
I think the key is in this page which contains the following:
Why do you provide a code module rather than documenting the API
interface in sufficient detail for me to implement it myself?
Two
reasons: Complexity/efficiency — Since all of MEGA's crypto logic runs
on the client side, you'd be looking at a project exceeding 5,000
lines of code. And, as natural language is rather inefficient when it
comes to specifying algorithms, the documentation would be similarly
voluminous. Consistency/interoperability
Ambiguities in the
specification or its imprecise interpretation would inevitably lead to
undesired behavioural differences between implementations
To me, this says that you have to use their client-side code, not your own. And that appears to be based on C++. Now if your language of choice can call C++ dlls, then you may be oK, but it sounds like a large job.
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.