Related
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 4 years ago.
Improve this question
I've searched for the definition of an API in a programming language and I am still finding it hard to understand.
Could anyone advice me in simple, layman's terms:
What is an API?
How is it used?
When and where is it used?
Searches should include Wikipedia, which is surprisingly good for a number of programming concepts/terms such as Application Programming Interface:
What is an API?
An application programming interface (API) is a particular set of rules ('code') and specifications that software programs can follow to communicate with each other. It serves as an interface between different software programs and facilitates their interaction, similar to the way the user interface facilitates interaction between humans and computers.
How is it used?
The same way any set of rules are used.
When and where is it used?
Depends upon realm and API, naturally. Consider these:
The x86 (IA-32) Instruction Set (very useful ;-)
A BIOS interrupt call
OpenGL which is often exposed as a C library
Core Windows system calls: WinAPI
The Classes and Methods in Ruby's core library
The Document Object Model exposed by browsers to JavaScript
Web services, such as those provided by Facebook's Graph API
An implementation of a protocol such as JNI in Java
Happy coding.
An API is the interface through which you access someone elses code or through which someone else's code accesses yours. In effect the public methods and properties.
Well, in addition to all the answers, I am just adding an example.
As others said API stands for Application Programming Interface through which softwares can interact with each other. Note, not a human interaction.
Where it is used
An example: You are buying an item online through your credit card. You will provide credit card details and press 'continue' button. It will tell you whether your information is correct or not. To provide these results, there are lot of things in the background.
The application will send your credit card details to a remote application which will validate your information and send the result back to your application. API is used in this scenario.
I hope it helps for the beginners who don't understand really what API is.
ANOTHER EXAMPLE
Weather application
Without API - Weather application must open weather.com site and read the details as a human does.
With API - Weather application will send a message to weather.com and receive the result and then display it.
SOURCE - Various online resources
1) What is an API?
API is a contract. A promise to perform described services when asked in specific ways.
2) How is it used?
According to the rules specified in the contract. The whole point of an API is to define how it's used.
3) When and where is it used?
It's used when 2 or more separate systems need to work together to achieve something they can't do alone.
an API(Application Programming Interface) is a set of defined functions and methods for interfacing with the underlying operating system or another program or service running on the computer.
It is usually used by establishing a reference to a library in your software or importing a function from a dll.
It is used in one form or another in almost all software, being explicitly called in your program or implicitly called by the compiler.
API stands for Application Programming Interface, i.e. API is the way for an application to interact with certain system/application/library/etc.
For example, there are API's for OS (WinAPI), API's for other applications (like databases) and for specific libraries (for example, image processing), etc.
APIs are usually developed in a form consumable by a client application. For C/C++ applications, it a set header files and dynamic/static libraries. For Java - set of jars. And so on.
It is a set of software components that interact with one another. It provides a set of functions, variables, and object classes for the creation of an application, operating system or any other thing.
Conaider this situation:
Mark and Lisa are secretly a couple, and because of age difference they are not allowed to be together. Mark and Lisa meet every night when nobody is watching. They have estabilished their own set of rules how to comunicate when the time comes. He stands in her garden and throws the small rock at her window. Lisa knows that it is time, and responds by waving from the window and opening it afterwards so Mark can climb in. That was example how the API works.
The rock is initial request to another end. Another end waves, opens the window which basicaly means "Welcome in!".
API is almost like human language but for computers.
In layman's terms, I've always said an API is like a translator between two people who speak different languages. In software, data can be consumed or distributed using an API (or translator) so that two different kinds of software can communicate. Good software has a strong translator (API) that follows rules and protocols for security and data cleanliness.
I"m a Marketer, not a coder. This all might not be quite right, but it's what I"ve tried to express for about 10 years now...
An API is a set of commands, functions, and protocols which programmers can use when building software for a specific OS or any other software. The API allows programmers to use predefined functions to interact with the operating system, instead of writing them from scratch.
All computer operating systems, such as Windows, Unix, and the Mac OS and language such as Java provide an application program interface for programmers.
Source
An API defines the interfaces by which one piece of software communicates with another at the source level. It provides abstraction by providing a standard set of interfaces - usually functions - that one piece of software (typically a higher-level piece) can invoke from another piece of software (usually a lower-level piece).
For example, an API might abstract the concept of drawing text on the screen through a family of functions that provide everything needed to draw the text. The API merely defines the interface; the piece of software that actually provides the API is known as the implementation of the API.
It is common to call an API a "contract". This is not correct, at least in the legal sense of the term, as an API is not a two-way agreement. The API user (generally, the higher-level software) has zero input into the API and its implementation. It may use the API as-is, or not use it at all: take it or leave it!
A real-world example of an API is the interfaces defined by the C standard and implemented by the standard C library. This API defines a family of basic and essential functions, such as memory management and string manipulation routines.
Lets say you are developing a game and you want the game user to login their facebook profile(to get your profile information) before playing it,so how your game is going to access facebook?
Now here comes the API.Facebook has already written the program(API) for you to do it, you have to just use those programs in your game application.using Facebook-API you can use their services in your application.Here is a good and detailed look on API...
http://money.howstuffworks.com/business-communications/how-to-leverage-an-api-for-conferencing1.htm
Application program interface (API) is a set of routines, protocols, and tools for building software applications. An API specifies how software components should interact and APIs are used when programming graphical user interface (GUI) components. A good API makes it easier to develop a program by providing all the building blocks. A programmer then puts the blocks together.
source:
http://www.webopedia.com/TERM/A/API.html
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 4 years ago.
Improve this question
We have 15 services build with Java Spring, they talk each other using REST .
Each time we add a new service to the pool we create from scratch all the code, including rest client code that will talk to other Services and the POJO classes used to map the resource(s) being requested.
We end up copy and pasting from the source code of other services into the new service.
I think it would be better to put all these POJO's and rest client code into a library for all the services to consume it, it would save us a lot of work coding, but "they" say we should not do that with microservices.
So, why is that?
We end up copy and pasting the exactly same code over and over again, I don't see the difference.
I would say "they" are wrong and you are right. There are several issues with copy and pasting client code:
If there is a bug in your client code, you will have to fix the bug in 15 places instead of just 1.
It slows things down. You now have to test and maintain multiple copies of the same code.
It is common practice to create client libraries and distribute them via a standard dependency manager like maven. Amazon does this https://github.com/aws/aws-sdk-java along with virtually everyone else.
In summary, you are right and Amazon is the strongest example supporting your opinion. They do exactly what you are suggesting for their web services, and they are arguably the largest most powerful player in the microservices space.
Also to address the concern of tight coupling in the other answer. Good apis are backward compatible, so a change to the api would not require upgrading all the clients even if they use the same client library.
The main issue is coupling. Sam Newman, author of Building Microservices puts it well:
In general, I dislike code reuse across services, as it can easily
become a source of coupling. Having a shared library for serialisation
and de-serialisation of domain objects is a classic example of where
the driver to code reuse can be a problem. What happens when you add a
field to a domain entity? Do you have to ask all your clients to
upgrade the version of the shared library they have? If you do, you
loose independent deployability, the most important principle of
microservices (IMHO).
Code duplication does have some obvious downsides. But I think those
downsides are better than the downsides of using shared code that ends
up coupling services. If using shared libraries, be careful to monitor
their use, and if you are unsure on whether or not they are a good
idea, I'd strongly suggest you lean towards code duplication between
services instead.
https://samnewman.io/blog/2015/06/22/answering-questions-from-devoxx-on-microservices/
I agree with the statements about coupling. I'm forced to use a specific set of Maven dependencies in a reuse scenario, and no one is allowed to update them. The result is that creating new services gets harder because the frameworks are out of date, and so is the documentation.
On the other hand, code reuse can save a lot of time and money, especially boilerplate code used in services, if it is well constructed and has proper tests.
I think there is a middle ground here that involves versioning and a certain amount of routine maintenance.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
I'm starting a new web based enterprise application, and I'm thinking of using Wavemaker.
I'm a fairly experienced java-ee developer, but it seems to me that even in this case, WaveMaker still makes sense to develop the application fast and focus on the business logic.
My questions are :
1- Are their any drawbacks to this platform
2- Can I do all the normal things from the server side easily (like sending mail,building birt reports, adding jobs)
3- Can I freely manipulate javascript (for example for specific animations, using plugins....)
4- Can I integrate realtime processes, like websockets ?
Thank you
I've used Wavemaker in an Enterprise application with success. We used quite advanced features such as heavy use of backend logic based on JavaServices, an run-time SQL database selector made inhouse, JS plugins for the frontend, obfuscation etc
We later recruited a devteam to take support of this application and, although the community is small, the team learn quickly and was able to maintain the code base.
As I see it, Wavemaker is a excellent tool if you like to:
deploy a web-based CMS for your midsized SQL database
deploy a smaller web control page for your java back end system
To answer you questions:
1) Small community: Although the community is friendly and on their toes, it is too small to ensure the type of feeback you might be used to. You will have to spend quite some time banging your head to the wall when you try to go beyond the example applications.
2) Yes, you have all the freedom you would expect from a Java backend. Simply said; each REST api is assigned to a Java Method, its up to you to implement the logic. I have built wavemaker on SQL, mongoDB. With email interactions, data parsing, file upload/download etc You name it
3) Yes, you can add JS plugins and customize the scripts generated by Wavemaker. You might want to make sure that you don't edit the auto generated JS, since they will be overwritten. but as soon as you found the right entry point you are free to customize just the way you like it.
4) Yes, since you build you own back end in java you are free to open up any type of communication you like to have. And since you are able to customize the front end js you will be able to read this data. But as I said in question 1 - there will only be a small community helping you
So to sum it up:
I vote for Wavemaker, but make sure to only deploy it if you application will be similar to the templates/demo provided, if you build a unique system you might like to look into other solutions.
All choices have drawbacks. There is not a lot of WM expertise to be had. You'll need to deal with some issues in terms of the library at hand, dojo, spring etc instead.
you can,but it requires some java knowledge. You are operating in a spring MVC you can
you can, you are operating in a dojo client there
possible, probably. worth the effort, doubt it.
1- Drawbacks- It's enterprise focused platform, so will require own effort to learn it.
2- Yeah, you can do pretty much all normal things (at least from my experience, till now)
3- The tool has kind of open-source configuration so its easy to manipulate or customize your codes if needed
4- From my experience, WaveMaker has one of the best and most diverse integration options available.
It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
Closed 11 years ago.
I currently run a website on LAMP, I am currently in the process of refactoring my code from normal php to Zend framework with Doctrine. I am happy with setup but often find function not found errors on live site cause I have renamed function. Which is frustrating as most of time is wasted is patching these errors.
So I have decided to switch from php to java as the code gets compiled, so just error will not go to live site. With java netbeans will work better.
But as I have not been in touch to j2ee for many years. What is the best replacement for my above setup in java?
Option 1. Jsf 2 with Hibernate
Option 2. Seam
Option 3. Spring
Option 4. Struts with Hibernate
My server has 24 gig ram and 2 core i7 processor and ssd drive on raid 0
Will my server handle the same amount of visitors if java was used without any performance issues?
I like the way I can update my site without losing live sessions(logged-in users). Can I do the same in Java? from my experience each update to site will redeploy the App which resets all the Active Sessions.
I love to consider .Net but from what I have read on most forums, no one recommends it?
Kind regards
Zerone
You problem is not switching to Java from PHP your problem is an good test coverage via unit and in particular with integration tests. From what you wrote the best thing might be to take a look at Selenium and to automate testing as most as possible. You need a complete infrastructure to deploy to a test system and run integration tests on it (Selenium) and after that you can say everything is ok.
Java will perform better, but switching to Java seems like overkill for this situation. That said, I would recommend something based on Spring and Hibernate. Spring can be a real godsend for configuring just about anything in Java and Hibernate is similar to Doctrine.
Apache Tapestry would make a good presentation toolkit for your site. It's a great templating library that is cleaner than JSP.
Java has a large variety of solutions to the same problem. Currently, the mainline Java solution to presenting items on the web is Java Server Faces.
Older (which doesn't always mean worse) solutions include Struts, Apache Tapestry, (parts of) Spring, etc. These solutions benefit from maturity, having an established following, etc. Basically they are good solutions because people already know the points where they fail, and already know how to work around them. The new solutions attempt to remove these pain points, and thus suffer from new pain points. Think of it as not noticing your headache until after you fix your broken arm.
Java will perform much better because the code that delivers the web pages is already in memory, so it avoids a number of items that take time (process spawning, disk access, webserver to language engine communications, etc). There are other PHP solutions which also attempt to solve similar problems using similar techniques; however, PHP has a different coding background and style. For example, Java doesn't need to discard any state between web page requests, something that PHP does (and often uses a number of libraries and workarounds to mitigate).
My recommendation is to use Java, but realize that a direct port will incur a lot of unnecessary expense. Choose a web facing toolkit (JavaServerFaces is the newest and part of the Java EE standard), and start off by porting the static portions of the HTML web pages. Organize your requests by scope (how long the side effect of the request should persist), and use the Servlet standard to store the artifacts generated by the request in the appropriate application, session, request, etc scope.
On the database side of things, there are many standards and solutions to pick from too. Personally, as you don't have a lot of legacy concerns, I would go with JPA. While it is not really a 100% complete solution, it will push you to use an interface which can be replaced by better implementations over time, without the need to recode your application. By stating it isn't 100% complete, I mean that you need to select a JPA provider as the default provider probably won't meet your real-world production needs. That said, the default provider should sustain development oriented work, and JPA's standards should protect you from unexpected differences when you run the code against different environments.
Whether you wish to fully restructure you code into a Java EE multi-tier architecture, of if you just want to embed a large Servlet (server faces is a type of servlet solution) that does everything is more of a function of how much you wish to architect your code. It is not a porting problem. That said, the biggest benefits of a typical Java solution over a typical PHP solution is that the Java architecture is designed to work faster and provide more features out-of-the-box. If you intend to do a port with no rearchitecting, you might be better off just finding out the bottlenecks in the PHP code and fixing them.
if you dont use ajax, i prefer 4 (struts + hibernate):
jsf needs an little bit of expiriences on such heavy load (getter-methods must be fast and so on).
if you use ajax, i prefer an combination of 3 and 1
regards
peter
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I have recently been exposed to naked objects. It looks like a pretty decent framework. However I do not see it in widespread use like say, Spring. So why is this framework not getting any mainstream application credit. What are its shortcomings as you see?
From my experience using NOF 3.0.3...
The good:
Automagically generates an DnD UI for your domain objects, like what db4o does for persistence.
This is what MVC was always meant to be, according to the MVC pattern creator.
The framework only asks your domain objects (POJOs) to be subclassed from AbstractDomainObject thats all the minimum wiring.
The framework favors convention OVER configuration: lots of annotations no freaking XML config giles.
Works great for prototyping along with db4o for persistence.
Out of the box functionality for Hibernate.
In my case, I required like 30 mins from Download to Hello world app. (IntelliJ IDEA IDE)
Deployment as JNLP, standalone, Web (NOX embedded Jetty or Scimpi flavor) and Eclipse RCP.
The NOF team is ALWAYS there for you when you ask for help in the forums.
The Naked Object Pattern is an awesome idea, do yourself a favor and take your time to grok it.
Theres a lot of usability flaming going on around the Drag and Drop GUI, but if your prospective end users simply can't work with the DnD UI then you are in deep trouble anyway.
The bad:
None that I can think of.
The kinda ugly:
No Swing components allowed, so say goodbye to JGoodies and all your favorite Swing component sets. The UI components are custom made; to get you an idea they look like early 90's VB controls. But there's a SWT port in the works.
The multiline line field for long strings has some issues. (NOF 3.0.3)
DnD UI for images is kinda buggy.
The validation code for getters n setters only fires if the domain object is modified from the UI. (This is probably wrong due to my n00bness, lets hope a NOF committer corrects me)
If an object is modified from a non-ui thread, lets say a b.g. worker, such object will
not update its view on screen. This invalidates a use case such as representing a mail queue in real time on the DnD autogenerated UI. (Again)
Veikko
I've been working on the naked objects approach for over a year now and I haven't even begun to scratch the surface of the possibilities it provides for your system's architecture. To properly utilize it though, it requires that you create a paradigm shift and seek out full OO solutions and revert from resorting to functional duck tapes, because the paradigm seems to work only when you create a design that would allow for high-level development.
Having said that, I absolutely love how Django has implemented naked objects within it's Django Models. Most of the things I love about the framework have been, what I come to believe, a direct result of it's models and there are some wows off the top I'd like to share about the architecture:
Model fields, that map to table columns, are behaviorally complete objects--they know how they're represented in both the application and database domain, how they're converted between the two and how the information they hold is validated and displayed to the user visually for inputs. All of this utilized with a single line of code in your model. Wow!
Managers are attached to models and provide CRUD and any generic operations on collections, such as reusable queries (give me the last five blog posts, most occuring tags, etc.), mass delete\update operations, and business logic performed on instances. Wow!
Now consider you have a model that represents a user. Sometimes, you'd only like to have a partial view of all the information a user model holds (when resetting a user's password you may only need need the user's email and his secret question). They've provided a Forms API that exactly displays and manages inputs for only parts of the model data. Allows for any customization of the what/how in handling user input. Wow!
The end result is that your models are only used to describe what information you use to describe a particular domain; managers perform all the operations on models; forms are used for creating views and for handling user inputs; controllers (views) are only there for handling HTTP verbs and if they work with models it's solely through managers and forms; views (templates) are there for the presentation (the part that can't be automatically generated). This, imho, is a very clean architecture. Different managers can be used and reused across different models, different forms can be created for models, different views can use different managers. These degrees of separation allow you to quickly design your application.
You create a ecosystem of intelligent objects and get a whole application from the way they're interconnected. With the premise that they're loosely coupled (lot's of possibilities for letting them communicate in different ways) and can be easily modified and extended (a few lines for that particular requirement), following the paradigm you really do get an architecture where you a component write once and then reuse it throughout your other projects. It's what MVC should have always been, yet I've often had to write something from scratch even though I did the same thing a few projects ago.
It has been successfully used here in Ireland.
I think reasons why it hasnt been more popular are:
You need a lot of confidence in the toolkits you are using
It makes the GUI a risk factor instead of a no-brainer (both technically and in usability testing)
Its not applicable to the web (as far as I know), which is where most of the focus is as present...
I've only just seen this. A couple of minor corrections, otherwise most of the comments are very fair.
1) 'The framework only asks your domain objects (POJOs) to be subclassed from AbstractDomainObject thats all the minimum wiring.'
Naked Objects does not require the domain objects to be subclassed from AbstractDomainObject, although that is typically the most convenient thing to do.
If you don't want to inherit, all you need to do is provide a property of type IDomainObjectContainer, and the framework will then inject an container into your objects when they are created or retrieved. The container has methods for Resolve(), ObjectChanged() and NewTransientInstance(), which are the three minimalist points of contact with the framework that you must use, so that the framework remains in synch with your domain objects.
2) 'Works great for prototyping along with db4o for persistence'. We're quite keen on the idea of working with db4o, but I'm not aware of anyone who has made Naked Objects and db4o play together. If anyone has done this, I'd like to hear more about it.
3) 'The general model of citzen programmer as espoused in the smalltalk and naked object communities ...'. We have never espoused that idea, and I don't agree with it. Naked Objects is NOT about encouraging users to program. I believe firmly in the role of the professional developer - Naked Objects just helps them to write better software and more productively.
Richard
I have played with it last year or so, and concluded it is very easy to work with.
The strength of Naked Objectsis that you get a GUI structured according to your data model for free. The disadvantage is that a typical user does not think about his proces as a collection of records.
My conclusion was that Naked Objects is really great for an internal application which conceptually deals with records, like an inventory application or bill processing application.
If you need anything different adapting the framework to your wishes may just be a lot more work than using a framework written to support the kind of application you want.
By the way, there is a Web rendering option; see the demo at Naked Objects Demo.
Gareth makes some excellent points.
There are other issues, such as the fact that it's hard to control the look and feel, and they are counter-intuitive to people who have become used to the window model. There is also something of a modelling issue, in that not all application domains lend themselves well to direct oject representation.
The general model of 'citizen programmer' as espoused in the smalltalk and naked object communities also comes to bear as a questionable idea. Most users don't seem to be hugely bothered with changing the functionality themselves, so thinking in objects is not that useful.
Probably the reason it hasn't gotten more attention is that the J2EE world has become so used to piling on so many layers onto an application, that naked objects comes across as naive.
Where are our services? You mean that any naked object gives me immediate access to the database? What if we needed to expose the application with RMI calls?
Plus there isn't as much to market, because it puts the burden of developing a successful application squarely on the application developers not the framework developers :)
I guess NakedObject definitely has its relevance and its more than time that developer community refocuses on what is really paying them: the business.
Instead, we mostly spend our time with infrastructure, protocols and all that technical crap. I have seen such miss constructed applications and I even did some myself following the mainstream, teaching you that layering a system is always a good thing to do. The worst thing is that if you ask some developers about what kind of business the company they are working for does, you’ll find at least some who worked for the company for years without gaining a deeper understanding of the business.
However, I don’t believe that NakedObject will attract a vast majority of developers (even those who are inspired from DomainDrivenDevelopment) simply because people love to construct UIs and taken that job away from them, directing their work towards businesses needs, is simply not what they want: We are all VB jerks.
NakedObjects (NO) are good for rapid prototyping. You can concentrate on Domain Model while not paying attention to GUI, DB and other parts of your solution. For production it requires alot of improvements (bugs fixing, data mapping, gui, etc.) in NakedObjects framework itself.
So if you need to get some kind of "proof of concept" for your solution, you may use NO. But for production be ready to invest resources into development of NO framework.
BTW, recently we are working on creating DnD viewer based on GWT for NO 4.0.
widespread use of technology has no strong correlation to technological quality.
The nakedobject system is difficult to use in combination with type objects:
if I'm selling different kinds of products and need different data for different products, it is difficult to constrain the data on the product type.
NO lost momentum when they switched licences. (to GPL+Commercial, not the recent move to Apache)
Did you take a look at jmatter?
[edit]
And another one: it makes it obvious to non-programmers if you can deliver. Spring is very much in the technological domain, NO means a developer has to talk to users. Large organisations don't do that.