What is API?
What is Importance of it?
give me example of it?
how can developer use API?
For a broad answer to your question you can check wikipedia:
http://en.wikipedia.org/wiki/Application_programming_interface
An API is an abstraction that describes an interface for the interaction with a set of functions used by components of a software system. The software providing the functions described by an API is said to be an implementation of the API.
An application programming interface (API) is an interface implemented by a software program which enables it to interact with other software. It facilitates interaction between different software programs similar to the way the user interface facilitates interaction between humans and computers. An API is implemented by applications, libraries, and operating systems to determine their vocabularies and calling conventions, and is used to access their services. It may include specifications for routines, data structures, object classes, and protocols used to communicate between the consumer and the implementer of the API
What Good Are They?
APIs allow us to tie functionality into websites that would otherwise take an enormous amount of time and effort to build from scratch. APIs are a sanctioned way of reusing someone else’s functionality without having to build it all yourself.
http://en.wikipedia.org/wiki/Application_programming_interface
Related
I want to dive into the whole diversity of tools which provide connection between programs over the network.
To clarify the question, I divide it on subquestions:
Why some groups of programs (or specific tools/frameworks/approaches with programming languages where this frameworks can be used) were popular in each period of time? (I expect description of problems which were solved, description of tools, why those tools are considered as best solution to those problems at that time, why some tools lost popularity)
What is the entire history of software communication over the network? (tools/approaches popularity precisely to decades)
What are the modern solutions to this problem?
I can distinguish only two significant approaches.
RPC, RMI and their implementations (I saw this, but it is about concrete problem and specific tools to solve this problem, I want to see the place of this problem in the whole picture of interconnection programs over the network. I heard about implementations: ONC RPC, XML-RPC, CORBA, DCOM, gRPC, but which are active now? which are reasonable to use? which are preferable and why? I want answers not to be opinion based, so I accept answers like "technology A better than technology B for problem X because ..." only if there is reliable research/statistics or facts). I heard that RPC and RMI were popular 10 years ago. Are they still?
Web services: REST, SOAP.
Am I miss something? Maybe there are some technologies which solve problem completely new way? Maybe there are technologies which can be treated as replacement to RPC(RMI) and Web Services? Can we replace RPC(RMI) by REST for any task? Can we replace RPC(RMI) by REST only for modern tasks? Should I separate technologies not as RPC and Web Services, but in some other manner?
As a partial answer, I can give you my feedback on the use of RabbitMQ.
As explain here, it provides a lot of different ways to use it :
RPC by implementing a "callback" queue
One to one, one to many routing strategy to propagate your events through your whole infrastructure and target the right destination.
It comes with the ability to persist messages to avoid loosing data when a crash appears but also with some plugins to increase possibilities (e.g x-delayed plugin)
This technologie written in Erlang is powerful and is a must try in term of communication between programs.
To your question „Am I missing something“: yes.
Very popular communication patterns are the so-called Event-Driven or Message-Driven protocols. This type of protocols are often used in distributed systems such web applications, microservices and IoT-Environments. The communication is complete asynchronously and allows building scalable and loosely coupled systems.
There are many different frameworks and methods for Event-Driven systems like WebSockets, WebHooks, Pub-Sub and Messaging-Librarys like AcitveMQ, OpenMQ, RabbitMQ, ZeroMQ and MQTT.
Hope this info helps for your research.
Has anyone used CKO_VENDOR_DEFINED to create a key or a data object?
There is hardly any documentation (including the mother load from Oasis) about how to do it, or which attributes are applicable/not-applicable.
Unfortunately, but hopefully understandably, I can not describe exactly what I am trying to do.
But the gist of it is that I need to be able to have a bit more attribute<=>mechanism flexibility with our kind of keys and the ability to modify a key on the token.
I'd really appreciate any pointers or help.
You can take a look at OpenPGP extension to PKCS #11 where CKC_OPENPGP is defined as:
#define CKC_OPENPGP (CKC_VENDOR_DEFINED|0x00504750)
I've seen also commercial implementations introducing CK*_VENDOR_DEFINED extensions this way.
(AFAIK) vendor defined object types must be implemented inside the HSM unit firmware (in theory, the host-side cryptoki library could introduce some additional "virtual" object types, but this probably would not make any sense as the overall security model would stay the same -- because the host-side cryptoki code runs in an untrusted execution environment).
If you need more control than provided by the vanilla PKCS#11 you have some choices:
Use existing vendor extensions -- some vendors add their own extensions designed to solve common use-cases. Read your documentation or contact your vendor directly.
Implement a custom firmware -- some products allow the end-user to run a custom code inside the HSM device. You can implement your model this way.
SafeNet ProtectServer:
SafeNet ProtectServer HSMs offer a unique level of flexibility for
application developers to create their own firmware and execute it
within the secure confines of the HSM. Known as functionality modules,
the toolkits provide a comprehensive facility to develop and deploy
custom firmware.
Thales nShield:
Most nShield HSMs also support the unique ability to host critical
applications within the hardened security boundary, so you can
establish tamper-resistant business processes in addition to
protecting cryptographic operations.
Utimaco CryptoServer:
The CryptoServer Software Development Kit (SDK) is the professional
development environment for all Utimaco Hardware Security Modules. It
enables integrators and end-users to create specific applications,
e.g. proprietary algorithms, custom key derivation procedures or
complex protocols that run in the tamper-proof environment of the
CryptoServer Hardware Security Module. As the SDK provides full access
to the Utimaco base firmware, custom firmware modules can be developed
in a very short time frame.
Use some other technology -- do not use HSMs at all and leverage some other secure device. Specifically smartcards might be a viable alternative as some of them can be programmed (at least Java Card or MULTOS ones). On the other hand the performance and range of supported algorithms is quite limited here (depends on your use-case).
It is a general question.
I am not sure whether i could post this question here. As i search in the programmer section and it seems to me that it is meant for in-depth question on programming.
As i am not a programmer ,however, i would like to find out how is API related to a plugin.. Do they have and difference?
I have tried to google in the web but not able to find any answer to my own question.
Thanks in advance.
Justin
"An application programming interface (API) is a set of routines, protocols, and tools for building software and applications" (Wikipedia).
What this means is that you establish a connection to another program / service which provides you certain functionality, like data retrieving in case of the Twitter API or operations and commands like from the Win32 API. Without this interface, there would be no ("easy") way to make use of the program.
"A plug-in [...] is a software component that adds a specific feature to an existing computer program" (again, Wikipedia).
This means that you have already built an application but want to enhance its functionality / appearance. For instance, you have a table on an HTML page but want to make it searchable. You the could use the jQuery Data Tables plugin. In this case you take an existing piece of software and entirely integrate it into your application.
I guess, as a developer you have a very intuitive understanding of these two and thus can distinguish more easily. Nonetheless, I hope that my explanation made it a bit clearer for you.
If not, do you have any specific question?
When talking about the pros and cons of an API versus plugin integration, it is important to highlight that there is no right or wrong basically both have the same nature.
API stands for Application Programming Interface. An API basically defines how a component interacts with a system, facilitating the communication between them.
More integration flexibility. The merchant has total control over the integration and can make the checkout page look as desired.
A theme or skin is a preset package containing additional or changed graphical appearance details, achieved by the use of a graphical user interface (GUI) that can be applied to specific software and websites to suit the purpose, topic, or tastes of different users to customize the look and feel of a piece of computer software or an operating system front-end GUI.from Wikipedia
Easy and ready to use integration. Within a few minutes, the payment methods can be available at the checkout.
Is there a general standard (in development) towards RESTful services? Since it's HTTP, I'm not talking about the technical standard ofcourse, but a more common way of exposing methods and functionality and implementing those.
And if not, are there general rules, to follow when developing a RESTFul service?
Or should we base ourselves on general API design, where there's already tons of books written about. Only question then to bear in mind, does it always translate to the web as well.
No there is no standard for RESTful design. It is simply a style. Following the constraints of the style allows many different valid design approaches.
You cannot translate many general procedural API design guidelines into web API design because distributed computing has many different issues than library level APIs.
I am currently doing my research on building a chat system with more than 10k users connected online. I came across technologies and ways to do it such as jabber(XMPP), websockets, long polling, push. As far as I now, long polling might not work given the number of users. I know there is a lot of ways to accomplish this. I also know that facebook and Google chat systems are developed on XMPP.
I would truly appreciate if anyone could point me to the right direction. I believe all these methods and technologies out there are good depending on the scale of the project. I definitely need performance and scalability.
I've used Socket.io together with NodeJS for such a chat application. It scaled to over 10K concurrent users on moderate servers and there was a lot of room to grow.
This does depend on your limitations, tho.
What kind of hardware are you planning on using?
Which operating system would power your servers?
Which client platforms are you targeting?
Do you have an existing infrastructure you need to fit this into?
Do you have a previously selected programming language?
The existing skill sets your team members have and your team's ability to adopt new platforms and languages if necessary.
Take all of the above into consideration when making your decision.
Personally, I've found XMPP to be quite adequate, but a bit bloated for my purposes. YMMV.
You are comparing a fruit basket and three different variety of oranges.
XMPP is the only protocol that you have mentioned that actually is designed to support a chat system (of which many exist). The others are simply asynchronous messaging protocols/techniques. XMPP already supports http based chat via BOSH. Without a doubt, it will also support WebSockets when the specification is finalized. There is actually a draft of this already written, but at this point it appears to be a draft using a draft, so there will probably be few, if any, implementations.
Using XMPP would allow you to build on a proven technology for implementing a chat system and would allow you to choose what transport you want to use "under the hood". You haven't actually said whether you need a http based transport or not, but with XMPP you can use the stock tcp socket based transport or a http based one (BOSH) with the knowledge that it will also support WebSockets in the future.
The other benefit is of course that this is a widely used standard that will allow reuse of existing clients, servers and libraries in pretty much all popular (and not so popular) languages and platforms.
Scalability is not too much of a concern with the numbers you are quoting, as most (maybe all) existing xmpp servers will handle that many users.