I know some basic programming languages but im new at using API's.
Can someone please explain how, or where do i run my API's codes?
Will the API's be run on the website i'm trying to get my data from or can it be run on a client or from another different running environment or platform?
Apis should only (I say "should" because I am not sure that something like this can be done on the client side) to run on the server.
when you get information from an api you are not executing it on the client. you are only getting the data you requested for the endpoints you used.
Do you plan to use REST APIs as a consumer or producer? That is, do you want to expose your data, systems and processes as resources for an end consumer, or do you want to be the consumer creating applications that leverage services?
The Producer
To produce REST APIs, you'll need to run your API providers using a web server. Just about any web server will do, so long as it can map resource paths to functions. Some common ones are:
Node.JS with Express.js
Nginx with Python/Flask
Java using Spring
You should be able to run whatever you chose on nearly any hosting provider, cloud VM or wherever else you usually run websites.
The Consumer
You can use Rest APIs anywhere you have network connectivity. You'll find this commonly in mobile applications, web applications, IoT devices, etc where data are combined from multiple providers on to a single application for end users. The key feature as a consumer you'll be looking for is a directory of API providers from which you can build your application.
ProgrammableWeb maintains one such list.
I have a java codebase that seems to be using "com.google.api.services.cloudkms.v1.CloudKMS" to call KMS. The online docs says to use "com.google.cloud.kms.v1.KeyManagementServiceClient"
When i looked up both packages seem to be updated, however the reference docs recommend using the latter.
https://developers.google.com/resources/api-libraries/documentation/cloudkms/v1/java/latest/com/google/api/services/cloudkms/v1/CloudKMS.html
https://cloud.google.com/kms/docs/reference/libraries
Could someone tell me what is the difference between these 2 clients packages and if i should move to the one the reference links to?
In general, you should prefer the library referenced on the Reference Libraries page, currently com.google.cloud.kms. The examples and tutorials on the website will use this client library.
Probably more history than you need to know, but we have two client libraries because they run over different protocols. The new libraries (the one's listed on the reference page) use gRPC to communicate. This means less bandwidth and less time spent serializing/de-serializing JSON. On the flip side, gRPC requires HTTP/2, and some organizations can't/won't support HTTP/2 yet. As a result, we still publish and maintain legacy libraries that are REST over HTTP/1. It is strongly recommended you use the gRPC ones unless you can't use HTTP/2.
You can read more about the background and technical details in Kickstart your cryptography with new Cloud KMS client libraries and samples.
I have a usecase where I have to collect user events and store it in Kafka. Is it efficient to directly use Kafka clients in mobile apps and websites to produce messages directly to Kafka instead of a middle layer. Is Kafka designed to handle millions of concurrent connections?
Technically you can do it. The main reason people do not do it, especially for mobile apps, is that it would rather be difficult to maintain a long-term evolution of the product, control its security or even its scale.
In the past years, Kafka Clients API has evolved dramatically (for the best but, it's still a change). It also includes authorization and authentication mechanisms, but there's not much freedom on what you can do with those. Kafka is not built upon a standardized protocol and technology-agnostic specification like JMS that could be thought as a bit more flexible.
Also, between major versions, compatibility is not guaranteed, as for most existing technologies. It may happen that you need to keep multiple server versions for a long time just because some mobile clients are still outdated and there's coupling to a specific client version, that itself is coupled to a specific server version.
On the other side and for the same reason, it could also happen that you would need to keep handling older versions of the messages schemas for a long time, just to keep older clients happy.
That's when HTTP and, more specifically, the API gateway pattern, comes into place.
HTTP APIs are easier to throttle, perform rate limiting, applying custom security policies, custom authentication/authorization strategies, etc. And they are based on a standard protocol that's used all over the Internet.
There are also advantages of using HTTP when you plan to have some partner integrations using your backend platform. As they can do it easily without changing the technology stack.
By not exposing Kafka to the outside clients, you can change the underlying technology stack later without impacting the clients. To be honest, although Kafka is a brilliant piece of technology, it's difficult to compete with HTTP for internet communication. Kafka actually provides a REST Proxy, an HTTP based client that could be possibly thought to be used for this sort of things.
i'm just a beginner in cometd , and i'm interested and wanted to learn what cometd is and what for it is used i googled it out and found some resource.Under the following link
1.http://docs.cometd.org/reference/installation.html#d0e346.
I tried out with the given demo but i could not able to get the expected output from it. can anybody post some resource url's so that i can learn ?
Disclaimer: I'm the CometD project leader.
CometD is a set of library to write web applications that perform messaging over the web.
Whenever you need to write applications where clients need to react to server-side events, then CometD is a very good choice. Think chat applications, online games, monitoring consoles, collaboration tools, stock trading, etc.
See more at the preface.
CometD ships a JavaScript client library, a Java client library and a Java server library.
This allows you to write applications in the browser with fine-grained logic and control on the server.
The server library, being in Java, leverages the high scalability of the JVM and the powerful asynchronous I/O API that the JVM and the Servlet specification provide.
CometD is transport agnostic: you write your applications using high level APIs, and CometD takes care of delivering the messages over the wire using the best transport available: WebSocket or HTTP, also providing a transparent fallback in case WebSocket does not work.
CometD provides a clustering solution called Oort that allows you to scale horizontally your web applications.
CometD comes with a ton of features and an extended documentation along with tutorials and demos you can use as a starting point for your project.
Join CometD to start hacking on your CometD-based web applications.
The CometD tutorials are currently written for CometD 2.x, but a port to CometD 3.x (the current version of CometD) is currently underway, so that requires a bit of patience.
But you can start right away by following the primer and deploying the demos.
I hope you can get started with CometD with the above references.
Drop an email on the mailing lists for any help you may need.
I have heard a lot of people talking recently about middleware, but what is the exact definition of middleware? When I look into middleware, I find a lot of information and some definitions, but while reading these information and definitions, it seems that mostly all 'wares' are in the middle of something. So, are all things middleware?
Or do you have an example of a ware that isn't middleware?
Lets say your company makes 4 different products, your client has another 3 different products from another 3 different companies.
Someday the client thought, why don't we integrate all our systems into one huge system. Ten minutes later their IT department said that will take 2 years.
You (the wise developer) said, why don't we just integrate all the different systems and make them work together? The client manager staring at you... You continued, we will use a Middleware, we will study the Inputs/Outputs of all different systems, the resources they use and then choose an appropriate Middleware framework.
Still explaining to the non tech manager
With Middleware framework in the middle, the first system will produce X stuff, the system Y and Z would consume those outputs and so on.
Middleware is a terribly nebulous term. What is "middleware" in one case won't be in another. In general, you can expect something classed as middleware to have the following characteristics:
Primarily (usually exclusively) software; usually doesn't need any specialized hardware.
If it weren't there, applications that depend on it would have to incorporate it as part of their application and would experience a lot of duplication.
Almost certainly connects two applications and passes data between them.
You'll notice that this is pretty much the same definition as an operating system. So, for instance, a TCP/IP stack or caching could be considered middleware. But your OS could provide the same features, too. Indeed, middleware can be thought of like a special extension to an operating system, specific to a set of applications that depend on it. It just provides a higher-level service.
Some examples of middleware:
distributed cache
message queue
transaction monitor
packet rewriter
automated backup system
Wikipedia has a quite good explanation: http://en.wikipedia.org/wiki/Middleware
It starts with
Middleware is computer software that connects software components or applications. The software consists of a set of services that allows multiple processes running on one or more machines to interact.
What is Middleware gives a few examples.
There are (at least) three different definitions I'm aware of
in business computing, middleware is messaging and integration software between applications and services
in gaming, middleware is pretty well anything that is provided by a third-party
in (some) embedded software systems, middleware provides services that applications use, which are composed out of the functions provided by the hardware abstraction layer - it sits between the application layer and the hardware abstraction layer.
Simply put Middleware is a software component which provides services to integrate disparate systems together.
In an complex enterprise environment, there are a number of challenges when you need to integrate two or more enterprise systems together to talk to each other. Normally these systems do not understand each others language as they are developed on different platforms using different languages (like C++, Java, Cobol, etc.).
So here comes middleware software in picture which provides services like
transformation of messages formats from one app to other,
routing and enriching messages besides taking care of security,
encryption,
validation and
applying different business rules to these messages.
A typical example of middleware is an ESB products like IBM message broker (WMB/IIB), WESB, Datapower XI50, Oracle Fusion, Mule and many others.
Therefore, middleware sits mostly in between the service consuming apps and services provider apps and help these apps to talk to each other.
Middleware is about how our application responds to incoming requests. Middlewares look into the incoming request, and make decisions based on this request. We can build entire applications only using middlewares. For e.g. ASP.NET is a web framework comprising of following chief HTTP middleware components.
Exception/error handling
Static file server
Authentication
MVC
As shown in the above diagram, there are various middleware components in ASP.NET which receive the incoming request, and redirect it to a C# class (in this case a controller class).
Middleware is a general term for software that serves to "glue together" separate, often complex and already existing, programs. Some software components that are frequently connected with middleware include enterprise applications and Web services.
There is a common definition in web application development which is (and I'm making this wording up but it seems to fit): A component which is designed to modify an HTTP request and/or response but does not (usually) serve the response in its entirety, designed to be chained together to form a pipeline of behavioral changes during request processing.
Examples of tasks that are commonly implemented by middleware:
Gzip response compression
HTTP authentication
Request logging
The key point here is that none of these is fully responsible for responding to the client. Instead each changes the behavior in some way as part of the pipeline, leaving the actual response to come from something later in the sequence (pipeline).
Usually, the middlewares are run before some sort of "router", which examines the request (often the path) and calls the appropriate code to generate the response.
Personally, I hate the term "middleware" for its genericity but it is in common use.
Here is an additional explanation specifically applicable to Ruby on Rails.
Middleware stands between web applications and web services that natively can't communicate and often are written in different languages/frameworks.
One such example is OWIN middleware for .NET environment, before owin people were forced to host web apps in a microsoft hosting software called IIS. After owin was developed, it has added capacity to host both in IIS and self host, in IIS was just added support for Owin which acted as an interface. Also it become possible to host .NET web apps on Linux via Mono, which again added support for Owin.
It also added capacity to create Single Page Applications, Owin handling Http request/response context, so on top of owin you can add authentication/authorization logic via OAuth2 for example, you can configure middleware to register a class which contains logic of user authentification (for ex. OAuth2 implementation) or class which contains logic of how to manage http request/response messages, that way you can make one application communicate with other applications/services via different data format (like json, xml, etc if you are targeting web).
Some examples of middleware: CORBA, Remote Method Invocation (RMI),...
The examples mentioned above are all pieces of software allowing you to take care of communication between different processes (either running on the same machine or distributed over e.g. the internet).
From my own experience with webwork, a middleware was stuff between users (the web browser) and the backend database. It was the software that took stuff that users put in (example: orders for iPads, did some magical business logic, i.e. check if there are enough iPads available to fill the order) and updated the backend database to reflect those changes.
It is just a piece of software or a tool on which your application executes and rapplication capabilities with respect to high availability,scalability,integrating with other softwares or systems without you bothering about your application level code changes .
For example : The operating system on which your application runs requires an I.P change , you do not have to worry about it in your code , it is the middleware stack on which you can simple update the configuration.
Example 2 : You experience problems with your runtime memory allocation and feel that the your application usage has increased , you do not have to much about it unless you have a bug or bottleneck in your code , it is easily achievable by tuning middleware software configuration on which your application runs.
Example 3 : You have multiple disparate software and you need them to talk to each other or send data in a common format which is understandable by all the systems then this is where middleware systems comes handy.
Hope the information provided helps.
it is a software layer between the operating system
and applications on each side of a distributed computing system in a network. In fact it connects heterogeneous network and software systems.
If I am not wrong, in software application framework, based on the context, you can consider middleware for the following roles that can be combined in order to perform certain activities in between the user request and the application response.
Adapter
Sanitizer
Validator
I always thought of it as the oldest software I have had to install. The total app used a web server, a database server, and an application server. The web server being the middleware between the data and the app.