njyx

Have some fairly strong feelings about how much of a bad idea this is for twitter in the long run - posted here: http://www.3scale.net/2015/04/loosing-innovation-twitters-fi...

I have no idea if DataSift and NTT were good partners, but not having anyone else access the Firehose suggests they think they can cover all significant use-cases. This almost always turns out to be wrong.

It also sends another chilling signal to say "we're a platform, but when we feel we want to roll over part of the ecosystem we'll do it".

Yes - that's a great example, if you're not inviting people to try things on your platform you loose in the long run. It might be a genuine resource issue - but seems unlikely that there's no arrangement that would work!

Some thoughts on this - big error in the long run: http://www.3scale.net/2015/04/loosing-innovation-twitters-fi...

I think that's unfortunately just the first order aim. The second order is to provoke an even more extreme reaction from the other side which drives wedges and divisions where there were none (or were manageable). Pretty soon everyone is at war.

I think it assumes you want to be a part of something which makes a long term impact. If you just want a pay check, you probably aren't at a startup (or at least not for the right reason).

Public APIs is also a directory - you could now use the apis.json data to keep that directory info from getting stale. That's the point of the http://www.apisjson.org + search combination.

I guess we'll see if people find it useful - the point of this is: there is current NO structured meta-data about APIs out on the web and that will be needed if we're one day goingto find APIs with all their associated elements as easily as we can web pages today.

Hence the format http://www.apisjson.org (it's basically sitemap for APIs) and the search engine http://www.apis.io. The search engine is also open source so you can run your own, format is completely open.

So if we (3scale) get some benefit I won't be unhappy - but if more people start posting API info then it'll benefit everyone.

Main thing that's useful is that if it can pull in all the elements (def portal, specs, etc.) you get deeplinks to everything. Google also doesn't help finding some APIs easily since it just treats it as content or they aren't linked.

In the long run hopefully a lot of the fields in the apis.json files this pulls on will be machine readable (e.g. meta-data for things like major T&C provisions), pointers to libraries etc. so you could filter on that.

The apis.json format this looks for contains fields for formats like http://www.swagger.io/ which it could then pull in (or someone else could) to render the docs in line.

It's search v's directory. The idea is you can post meta-data on an API on your own domain using a format http://www.apisjson.org/ that can then be crawled. Right now you still submit links, but it'll start crawling. So then anyone can write a search engine (the code for apis.io is open source).

With a directory like programmableweb it's useful but you need to put your data into the repository - and then remember to update it.

Working again for me now, definitely being hit by a bunch of load.

This clearly had to be the best: https://twitter.com/pmonks/status/500421703441199106

Hackathon gold

Also see: http://apis.io/

This is a fantastic series - Class #4 "Last Mover Advantage" and a couple of the others are just great stand alone, but they are all good.

Here is the index: http://blakemasters.com/peter-thiels-cs183-startup

Do you need to register the APIs you use in APItools before doing this?

We monitor traffic in and out closely and we have multiple IPs out of the back. However, if you're doing heavy production usage there is an on premise version coming.

Runscope is a bit different in that it focuses more on API Testing, APItools focused on monitoring the live traffic to the APIs and controlling it with programmable middleware.

There's a bit overlap but it's definitely worth checking out both!

No - Mashape is a marketplace to signup for APIs. You can call APIs through the mashape but you don't get the middleware control layer or detailed alerts/analytics.

There will be an on-prem version of this too pretty soon. On the hosted we're benchmarking, but it'll depend where you're hosted. If you're Amazon EC2 you should see very low latencies.

Yep - fixing that.

VR could kick something like second life up a lot of notches - maybe the next FB buy?

AI is already here - the interfaces may be messy (Siri's speech interface or typing, but humans are using intelligent systems of varying degrees all the time. The real question is how people can adapt to that quickly changing world.

Brynjolfsson and McAfee's new book "The Second Machine Age"is awesome on the general effect of AI on society: http://www.amazon.com/Second-Machine-Age-Prosperity-Technolo...

This is really all about whether or not network providers can flips the switch and charge both sides of the traffic flow for traffic. They are trying to make that switch.

Ultimately charging large content sites more is going to spiral into charging all content providers, because behaviors will change, new services will get popular and everybody ends up having to pay on both sides. Netflix is already paying to get traffic from its servers to the peered internet.

The article isn't wrong, but it's a new situation when content providers start paying to peer explicitly. Netflix and other large players already pay for CDN structures to get content close to the last mile. Now they are going to be paying for the last mile in some sense also.

Fine for Netflix to do, but if prices rise and the thresholds where this applies lower, new services will get shut down due to cost.

Hopefully some ISPs will not charge and market "fast access to whatever you want" and not "fast access to whatever we chose based on what they paid").

Bitcoin as is, is more like a cloud service - you need the whole chain to be updated everywhere. You can do that P2P but you need full consistency. That's not a great property if you only have weak connections between nodes.

I guess if you are using the protocols for different things you can have different blockchains for every application - so that segments the effort.

This is a major problem though.

Kudos for using a HN page to stay in touch

Media types help in one dimension (data model) but they don't give you a complete definition of an API. Also - people aren't actively promoting and re-using them. The main aim here is to try bring the things which are clearly copyright free out into the open so they can be re-used and evolved. This doesn't happen in the REST API space at all right now.