#apis

📕 Access Kindle's private API in Node.js without a headless browser

Experiment to recreate my kindle-highlights project with Cursor / LLM assisted coding.

So welcome to the new era. AI is not just using tools we gave it. It now has opinions about how these tools should’ve been made. And instead of asking nicely, it gaslights everybody into thinking that’s how it’s always been.

Fielding’s rules emphasize that a truly RESTful API should embrace hypermedia (HATEOAS) as the central mechanism for interaction, not just use HTTP as a transport. REST is protocol-independent at its core; HTTP is simply a convenient way of using it. Clients should discover and navigate resources dynamically through links and standardized relations embedded in representations — not rely on hardcoded URI structures, types, or external documentation. This makes REST systems loosely coupled, evolvable, and aligned with how the web itself operates: through representation, discovery, and transitions. REST isn’t about exposing your internal object model over HTTP — it’s about building distributed systems that behave like the web.

Amazon S3 can now perform conditional writes that evaluate if an object is unmodified before updating it. This helps you coordinate simultaneous writes to the same object and prevents multiple concurrent writers from unintentionally overwriting the object without knowing the state of its content. You can use this capability by providing the ETag of an object using S3 PutObject or CompleteMultipartUpload API requests in both S3 general purpose and directory buckets.

The OpenAPI Specification (OAS) provides a consistent means to carry information through each stage of the API lifecycle. It is a specification language for HTTP APIs that defines structure and syntax in a way that is not wedded to the programming language the API is created in. API specifications are typically written in YAML or JSON, allowing for easy sharing and consumption of the specification.

I wrote recently about how you can use Mastodon’s API to make bots that post random images and make data charts, but you don’t have to automate just bots. Let me show you a few fun things you can do with your own profile.

I wrote recently about how you can use Mastodon’s API to make bots that post random images and make data charts, but you don’t have to automate just bots. Let me show you a few fun things you can do with your own profile.

The Physical Web is an approach to unleash the core superpower of the web: interaction on demand. People should be able to walk up to any smart device - a vending machine, a poster, a toy, a bus stop, a rental car - and not have to download an app first. Everything should be just a tap away.

The Physical Web is an approach to unleash the core superpower of the web: interaction on demand. People should be able to walk up to any smart device - a vending machine, a poster, a toy, a bus stop, a rental car - and not have to download an app first. Everything should be just a tap away.

The objective of APIs.json is to help fix this problem by making it easy for people to signpost where the APIs on a given domain are and provide information on how they work. The format is simple and extensible and can be put into any web root domain for discovery.

The objective of APIs.json is to help fix this problem by making it easy for people to signpost where the APIs on a given domain are and provide information on how they work. The format is simple and extensible and can be put into any web root domain for discovery.

Welcome to APIs.io - an experimental API Search service to help discover APIs on the web. The service uses the APIs.json proposed discovery format. To find APIs type your request in the search box.

Welcome to APIs.io - an experimental API Search service to help discover APIs on the web. The service uses the APIs.json proposed discovery format. To find APIs type your request in the search box.

Where REST is an architectural style for APIs, NARWHL is a framework intended to provide a roadmap for those needing to implement an API using current best practices but flexible enough to grow into the future.

Where REST is an architectural style for APIs, NARWHL is a framework intended to provide a roadmap for those needing to implement an API using current best practices but flexible enough to grow into the future.

API First talk from Gluecon '14, talking about putting the API behind all of your products and having a single stack. Presenter notes are included and probably necessary for when you don't have my interpretive dance to watch.

Collaborative design, instant API mock, generated documentation, integrated code samples, debugging and automated testing

Collaborative design, instant API mock, generated documentation, integrated code samples, debugging and automated testing

WebhookInbox receives HTTP requests and captures the data for later inspection.

WebhookInbox receives HTTP requests and captures the data for later inspection.

Nifty REST API browser

July 29-31, 2013 - 1555 Broadway St. Detroit, MI, USA

July 29-31, 2013 - 1555 Broadway St. Detroit, MI, USA

We already showed you how to build a Beautiful REST+JSON API, but how do you secure your API? At Stormpath we spent 18 months researching best practices, implementing them in the Stormpath API, and figuring out what works. Here’s our playbook on how to secure a REST API.

User Management and Authentication for Developers

User Management and Authentication for Developers

Tools that give application developers visibility into the conversations their apps are having with the services they rely on. Tools that make debugging and testing your API integrations as simple as any other line of code.

Les recently gave a talk on "Designing a Beautiful REST + JSON API" at the San Francisco Java Users Group, which covers 18 months of his research into API design.

Below is a compilation of APIs that have benefited from Machine Learning in one way or another, we truly are living in the future so strap into your rocketship and prepare for blastoff.

Returns the sentiment of Tweets. Two online APIs call the Twitter API to analyze Tweets from a given Twitter user or Tweets returned by a Twitter search query. The offline API analyzes texts of Tweets you've already got, one Tweet at a time.

Choose your username and language to start chatting with the world.

Choose your username and language to start chatting with the world.

Our API provides face recognition, facial detection, eye position, nose position, mouth position, and gender classification

Consume and distribute software in the cloud on the largest API hub in the universe.

Consume and distribute software in the cloud on the largest API hub in the universe.

This post is intended to help data scientists and engineers who in some capacity have implemented routines/algorithms/data that does a specialized function (e.g. machine learning) using a dynamically typed language, such as Python. The goal is to web-enable these routines/algorithms using an application programming interface (API).

Substitutability is a principle in object-oriented programming. It states that, in a computer program, if S is a subtype of T, then objects of type T may be replaced with objects of type S (i.e., objects of type S may be substituted for objects of type T) without altering any of the desirable properties of that program (correctness, task performed, etc.).

Without too much complication or any hardware source of randomness, this seems like a reasonable method for API key generation.

Without too much complication or any hardware source of randomness, this seems like a reasonable method for API key generation.

Twitter’s been around for over 6 years now, and it’s most of it’s early history has been forgotten. The amazing thing about twitter as a platform and community is that it’s evolution has come through it’s use. Through use, people together evolve new ways of communicating. The #hashtag, the retweet, the @reply, follow friday, trending topics, real time twitter search, explaining twitter trends, cc-ing users, etc… These were all creations of the user base, people tried out ideas and build them. Twitter the company later adopted the conventions of it’s community and formalized the tools. This letting the community of users create, and then adopting the practices is critical to how Twitter’s grown to be such an amazing platform. It’s also why new efforts to deliver a ‘consistent experience‘ are a terrible idea and if they succeed will kill twitter’s future innovation.

Twitter’s been around for over 6 years now, and it’s most of it’s early history has been forgotten. The amazing thing about twitter as a platform and community is that it’s evolution has come through it’s use. Through use, people together evolve new ways of communicating. The #hashtag, the retweet, the @reply, follow friday, trending topics, real time twitter search, explaining twitter trends, cc-ing users, etc… These were all creations of the user base, people tried out ideas and build them. Twitter the company later adopted the conventions of it’s community and formalized the tools. This letting the community of users create, and then adopting the practices is critical to how Twitter’s grown to be such an amazing platform. It’s also why new efforts to deliver a ‘consistent experience‘ are a terrible idea and if they succeed will kill twitter’s future innovation.

Conclusion -- corporate APIs are good for the corporations that own them, and pretty much bad for everyone else. I would be reluctant to develop on any corporate API unless I was prepared to have my work completely deleted or obviated or usurped by the platform vendor. You really don't have any power. However it's pretty much impossible to avoid them. But try to. And don't be a crybaby when you get hurt. permalink

postMessage is a new HTML5 Javascript API for allowing scripts on different domains to communicate with each other safely.

Robohash is a easy web service that makes it easy to provide unique, robot/alien/monster/whatever images for any text. Put in any text, such as IP address, email, filename, userid, or whatever else you like, and get back a pretty image for your site.

Robohash is a easy web service that makes it easy to provide unique, robot/alien/monster/whatever images for any text. Put in any text, such as IP address, email, filename, userid, or whatever else you like, and get back a pretty image for your site.

When people create HTTP APIs, one of the common decisions is about what format to use, usually revolving around “JSON or XML?”

Yep. Sorry to have to inform you. REST is totally over. The cool kids are moving on. We're building "Hypermedia APIs" now. Such is life.

Originally, this post was titled "A RESTful Reading List," but please note that REST is over. Hypermedia API is the new nomenclature. I've been doing an intense amount of research on Hypermedia APIs over the last few months, and while I didn't save every resource I found, I've made a list here of the most important.

My contribution to REST pedantry for the day:

My contribution to REST pedantry for the day:

So, by Roy’s strict criteria, hypermedia is a *precondition* of REST. Anything else should not call itself REST.

So, by Roy’s strict criteria, hypermedia is a *precondition* of REST. Anything else should not call itself REST.

Presentation given at phpDay 2011 in Verona, Italy.

The technique I’m going to describe consists in setting up a proxy to the Twitter API that lives in our computer, powered by Node.JS, that filters back responses based on arbitrary rules we setup. Not only does this give us the flexibility of using JavaScript, but it also means it will work with any Twitter client that leverages the API transparently. Yes, this includes the Twitter website!

The technique I’m going to describe consists in setting up a proxy to the Twitter API that lives in our computer, powered by Node.JS, that filters back responses based on arbitrary rules we setup. Not only does this give us the flexibility of using JavaScript, but it also means it will work with any Twitter client that leverages the API transparently. Yes, this includes the Twitter website!

I totally agree with this presentation

I would love to see every API to be RESTful, consistent, hypertext driven, and more importantly, interoperable. The reality is that getting consistent APIs is hard – particularly those that are done by distributed teams. For the record – I vehemently hate SOAP APIs and the SOAP mindset. I dislike RPC-style operation names tunneled over HTTP. I frown and cringe whenever I see unnecessary custom headers and complicated formats. I wish POST+XML goes away. I wish every API gets rewritten to the modern understanding of HTTP and REST, serving JSON. But I would rather spend my time enabling interoperability than preaching for consistency.

This idea crystallized for me yesterday when Jonathan Glick, a long-time digital journalist, tweeted, "I think #OWS was working better as an API than a destination site anyway." If you get the idea, go ahead and skip ahead to the documentation below. If you don't get, let me explain why it might be the most useful way of thinking about #Occupy.

But we've also learned that while web APIs enable us to tap into a wealth of data, they can only be relied upon in the short term. The expiration date of software we create has been shortened due to the whims of those who create the web APIs we rely on. IMO, this goes for almost anything with net-based DRM, as well.

"The IMified platform makes it amazingly easy to connect your existing applications to instant messaging networks or create stand alone IM bots for fun or getting work done. "

"Your writing, notes, and to-do lists online. SimpleText.ws stores your text and keeps it synced between your work, home, and devices like the iPhone. Unlike manual syncing, SimpleText.ws merges your changes so you'll never lose data."

"We’ve just released a brand new API for BlockChalk. It’s very easy to learn and use: requests are made via HTTP GET and POST, and data is provided in XML, JSON, and RSS formats. These new interfaces enable developers to do nearly everything that you can do at http://blockchalk.com. It’s now possible to build client applications, mash-ups, and other tools based on BlockChalk geolocation data and services."

I guess I missed a few updates on Adium Xtras. My copy was pinging every 15 seconds. "* 120 seconds between updates to be nicer to twitter"

"Anyway, here’s the question I want to put into the reader’s mind: should one spend time and effort making a frontend into an informal API through microformats, or to instead spend it on building a fully supported API or data publishing system that exists and operates separately? I think my stance is clear - i’m not against the theory of microformats, but i’m certainly going to differ with anyone who thinks it’s practical."

"This page should show you your twitter info if you're logged in."

"Feedback on the 0.3 API announcement went well, so it’s time to release a prototype of the server. The code is available from the weaveserver repository along with instructions for setting up a copy of the server and the local user creation API if you want to use that."

"What needs to be done to make the REST architectural style clear on the notion that hypertext is a constraint? In other words, if the engine of application state (and hence the API) is not being driven by hypertext, then it cannot be RESTful and cannot be a REST API. Period. Is there some broken manual somewhere that needs to be fixed?"

"At this point, the benefits of building RESTful services for the Web should be self evident. The Web has a particular architecture and it makes sense that if you are deploying a service or API on the Web then it should take advantage of this architecture instead of fighting against it. There are millions of deployed clients, servers and intermediaries that support REST and it makes sense to be compatible with their expectations. "

"store some tiny data in a tiny url"

"With Y!OS, we’re moving from a model in which each Yahoo! property develops much of its own technology to one where we share common data and frameworks that can be easily surfaced across multiple Yahoo! properties and off the Yahoo.com "

"The Recipe Sharing Protocol (RSP) is a standard for sharing and publishing recipe information over a network." Seems to be crying out for AtomPub. Or euthanasia.

"The EVE API is a platform created to allow third party tools (programs, web sites, etc) to access character and corporation data for the purpose of enhancing the EVE experience."

"You know what an application programming interface really is? An admission that you're too poor, cheap, or uncreative to build all the features your website needs." True, except that anyone who doesn't admit this is lying.

"As we wrote in July, the platform is the killer app of today's web and Yahoo! needs to get on board."

"OAuth aims to unify the experience and implementation of delegated web service authentication into a single, community-driven protocol."

"The best reason to always build out APIs for your product is that it makes it easier for the rest of the world to extend your product or service rather than start competitors."

"Put bluntly, it confirms Google's abject failure to monetize its API except by the indirect mechanism of contextual advertising."

"I just learned that two weeks ago Google officially put the SOAP search API on end of life status."

"XSL Flickr is a library of templates that allow XSLT (1.0 or 2.0) stylesheets to access the Flickr Services API."