Quotes About API

As your confidence in the API increases, then you flesh it out. But the fundamental rule is, write the code that uses the API before you write the code that implements it.

In other words, if you accept the default serialized form, the class's private and package-private instance fields become part of its exported API, and the practice of minimizing access to fields loses its effectiveness as a tool for information hiding.

The text you print and the text you read can become an important API.

My experience tells me that API users are really creative. Sometimes the API user's horizon is farther than that of the API designer. If there is a way to misuse something, users are likely to do so.

The most similar activity to writing an API is writing a book: one writer and a lot of readers. The readers know something of the writer, but the writer knows little or nothing about the readers. Guessing their skills and knowledge correctly is part of the delicate art of making an API that is easy to understand.

Giving up and writing another API to perform the same task avoids the problem of incompatibility. The old API can stay the same, so no potential problems occur for its clients, and the new API can offer new and better possibilities. The only problem here is that old clients will stick with the old API unless they rewrite their code and upgrade to a new version of the API.

Because you cannot speak to unknown clients, there are only two solutions: either find your users and do a usability study, or be use case oriented. Work with use cases—that is, visions of the API user's action—and then optimize specifically for these. Getting responses from users via a usability study is good and can verify that your expectations about the use cases are correct.

When a user of the API complains and requests the element to be visible, you can still make it visible. However, don't do so sooner than requested and not without a convincing use case!

One lesson we learned the hard way after years of NetBeans API development is, "Don't put setter methods in the true API." By "true API," we mean the interfaces that must be implemented to provide something. If setter methods are needed at all—and usually they aren't—they belong only in the convenience base classes.

So it's reasonable to ask, "Is there actually any reason to use abstract classes?" The short answer is "No." Abstract classes in an API are suspicious and often indicate an unwillingness to invest more time in the proper API design. The longer answer is, "Well, there might be reasons to use abstract classes in APIs after all.

The path of evolution depends on the type of interface: additions to an API are acceptable, while removing functionality is not. In SPIs removals are allowed, while additions are not.

The basic problem lay in the perception that an API is something that people call and an SPI is something that people implement.

This is just another example of API users engaging in "empiric programming." They don't care about what is right or wrong, but only what works and what doesn't. Because this coding style simply used to work, API users exploited it without any problems.

It's always good to motivate migration by means of some kind of bonus. For example, offer functionality in the new API that cannot be achieved in the old version.

Clean code can be read, and enhanced by a developer other than its original author. It has unit and acceptance tests. It has meaningful names. It provides one way rather than many ways for doing one thing. It has minimal dependencies, which are explicitly defined, and provides a clear and minimal API. Code should be literate since depending on the language, not all necessary information can be expressed clearly in code alone. -Dave Thomas, founder of OTI, godfather of the Eclipse strategy

One of the reasons why we were so successful in integrating with Facebook was because we saw people using Facebook to promote their event and link back to Eventbrite before Facebook Connect and before the event's API was even available.

Loic Le Meur, producer of LeWeb, Europe's largest tech conference, is an ardent fitness enthusiast and Quantified Self proponent. In August 2010, he suggested in a blog post that as people and mobile devices work together to provide highly personalized data, the human body itself becomes an Application Programming Interface (API), meaning that developers can now offer personalized mobile apps for each individual by letting their computer codes talk with each other.

I had to actually purchase a book to learn the API and write the client. It was pretty frustrating trying to learn the API and develop a product quickly.

With .NET once an API is published it's available to all programming languages at the same time.

You've probably seen latitude and longitude specfied in both degrees/minutes/seconds, such as (47°38'34'', 122°32'32''), and in decimal values, such as (47.64, -122.54). With the Geolocation API we always use decimal values. If

With stable, long-lived teams that own specific bits of the software systems, we can begin to build a stable team API: an API surrounding each team.

In many organizations, poorly defined team interactions and responsibilities are a source of friction and ineffectiveness. A team may have been told it is autonomous and self-organizing, but team members find they have to interact with many other teams in order to complete their work; and this feels frustrating. Another team may have responsibility for providing an API or service, but they don't really have the experience to do this effectively.

The Twitter team took the exact opposite approach. They built the API first, and exposed all the data that was crucial to the service, and then they built Twitter.com on top of the API.

Conventionally, a developer will create a piece of software, and once it's finished, expose a small part of its functionality to outside developers via the API. The Twitter team took the exact opposite approach. They built the API first, and exposed all the data that was crucial to the service, and then they built Twitter.com on top of the API.