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.
Related
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.
So I am new to web development and all I've learnt so far is how to write HTML and CSS to make web pages and forms.
I'm specifically looking for a language that will help me store the data that is input into the form onto a database for easy access later.
I think PHP does that, but I was looking for anything JAVA related, and somewhere I could learn how to do it.
So far,
I've looked into JavaScript tutorial on W3Schools, but it seems like JS only helps make the front end more dynamic, but doesn't help store the input data anywhere.
I've also looked into the AngularJS tutorial on CodeSchool and it looks like Angular helps present the forms in a better manner and again, not in storing data anywhere.
Once again,
1) What do you use to collect the data input into a HTML form and store it somewhere?
2) I don't need help making the actual form itself.
Me personally, i use PHP, it allows you to take the data that was inputted and store it in a database. You can also use JavaScript/JQuery with PHP via Ajax that will dynamically fetch and store data.
Any backend lang can do it (python, php, java, ruby, js with node), but each one has it own ways to do it. Even JS at client side can do it, using LocalStorage objects, but it not solve all problems at data storage yet.
Angular is just the client-side. You will need a server, which will handle the requests and store them into a database. I would work with Spring Boot (JAVA) on the server side, and Angular 2 on the client side. Use REST for the communication bewtween them. Its really not hard.
Node.js is a fast Javascript runtime combined with a low-level API similar to the standard libraries of many programming languages (file system access, buffers, streams, i/o, etc.).
Angular is a model-view-controller framework for client-side JS development. It can be used with Node.js as a backend, or anything else. Its main feature is 2-way data-binding, and addresses most of the concerns of a single-page web app within the framework.
React is often compared to Angular, because it is a front-end library, but it is not a framework. It is simply the view layer, with a large ecosystem of open-source projects supporting it. The big conceptual difference is a uni-directional data flow, rather than 2-way data binding. You need a lot more besides React to make a full application, but React handles it's use case exceptionally well. React is amazing on the client side, but it’s ability to be rendered on the server side makes it truly special. This is because React uses a virtual DOM instead of the real one, and allows us to render our components to markup. Node.js makes a great backend for React as well, but again, it can work with any backend.
The MEAN stack is a popular web development stack made up of MongoDB, Express, AngularJS, and Node.js. MEAN has gained popularity because it allows developers to program in JavaScript on both the client and the server. The MEAN stack enables a perfect harmony of JavaScript Object Notation (JSON) development: MongoDB stores data in a JSON-like format, Express and Node.js facilitate easy JSON query creation, and AngularJS allows the client to seamlessly send and receive JSON documents.
MEAN is generally used to create browser-based web applications because AngularJS (client-side) and Express (server-side) are both frameworks for web apps. Another compelling use case for MEAN is the development of RESTful API servers. Creating RESTful API servers has become an increasingly important and common development task, as applications increasingly need to gracefully support a variety of end-user devices, such as mobile phones and tablets.
This was the overview of all the new booming technologies.. Based on this you can decide what you need and what you want to learn.. Thanks, Hope this overview helps you to decide.
My favorite for Rest Api is Flask(python micro framework) it is build for create Rest Api. and for php falcon has it own micro frame work. if you use nodejs it is easy to communicate between backend and frontend and good with not sql dB like mongo db.
The right answer should be the database or localStorage/sessionStorage.
The decision in between which answer chose, depends if you want to share the data between Browsers/Computers or if you just want to temporarily store the data for the user so he won't need to fill the form once again.
For temporarily storage chose localStorage/sessionStorage (javascript).
For other cases chose to store the data in a Database.
I've done some research and I've noticed that in a lot of examples Symfony2/AngularJS apps the frontend and backend are combined; for example, views use Twig.
I'd always thought that it's possible (and common practice) to create the frontend and backend separately and just join them by API. In that case if I want to change a PHP framework I will can do it without any problems and it will be enough to keep API.
So what are the best practices for doing it? It would be great if you could explain it to me and even greater if you just give me a link to good example on github or something.
We have been developing some projects using the same approach. Not only I think it doesn't have any "side effect", but the solution is very elegant too.
We usually create the backend in Node.js, and it is just an API server (not necessarily entirely REST-compliant). We then create another, separate web application for the frontend, written entirely in HTML5/JavaScript (with or without Angular.js). The API server never returns any HTML, just JSON! Not even an index structure.
There are lots of benefits:
The code is very clean and elegant. Communication between the frontend and the backend follow standardized methods. The server exposes some API's, and the client can use them freely.
It makes it easier to have different teams for the frontend and the backend, and they can work quite freely without interfering with each other. Designers, which usually have limited coding skills, appreciate this too.
The frontend is just a static HTML5 app, so it can (and we often did) easily be hosted on a CDN. This means that your servers will never have to worry about static contents at all, and their load is reduced, saving you money. Users are happier too, as CDNs are usually very fast for them.
Some hints that I can give you based on our experience:
The biggest issue is with authentication of users. It's not particularly complicated, but you may want to implement authentication using for example protocols like OAuth 2.0 for your internal use. So, the frontend app will act as a OAuth client, and obtains an auth token from the backend. You may also want to consider moving the authentication server (with OAuth) on another separate resource from the API server.
If you host the webapp on a different hostname (e.g. a CDN) you may need to deal with CORS, and maybe JSONP.
The language you write the backend in is not really important. We have done that in PHP (including Laravel), even though we got the best results with using Node.js. For Node.js, we published our boilerplate on GitHub, based on RestifyJS
I asked some questions in the past you may be interested in:
Web service and API: "chicken or egg"
Security of an API server: login with password and sessions
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.
I would like to make some calls to a url from a mapreduce in mongo, but I don't find anyway to do that in javascript except jQuery or lower layers that seem to be accessible only from web browsers
If it may help drive the discussion, I want to call localhost, a c++ server can do complicated things that I can't do in javascript (big libraries)
While MapReduce is written in the JavaScript programming language in MongoDB currently, there is not a general set of APIs that allow access to a richer set of platform capabilities.
By design, you cannot access the network (or localhost), files, process, etc. stacks of the host operating system. It's intentionally limited to just the features of MongoDB, and even that is restricted so that the MapReduce will perform optimally.
You will need to write your queries in a different platform and merge the results, or consider other database options.
No. It's a database, not a programming language.
What you can do, however, is to dynamically create your query (from c++ or another language) which would call the server or put the required data dynamically inside.