Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Future of APIs: APIs aren’t the endgame they won't stay forever

blog.goodapi.co

Post reply on HN
Print view View original

51–60 of 63 posts

Re: The Future of APIs: APIs aren’t the endgame they won't stay forever

#51

Post by romaniv »

patkai wrote: post #46
romaniv wrote: post #44

As someone who worked on a whole lot of integration projects in the recent past, I think network APIs can be "solved", but not by the means this article describes. JSON-LD looks like a reimplementation of something that was already done by XML, XML Schemas and WSDL. If several technologies that were designed to be semantic failed at automating network API integration, why would you think a sub-format for JSON will su…

"distributed Prolog on the global scale. Systems would exchange constraints until they reach a mutually agreeable solution" - wow, I'm impressed, but not sure I fully get this. Any pointers or writeups on this or something similar?

I simply verbalized something that I think is imminently possible. Prolog operates on rules and facts, both of which involve symbols. If you fix the meaning of some symbols globally, you can run queries that will (potentially) derive semantically meaningful information. There is nothing stopping two systems from exchanging rules. If you keep track of which symbol belongs to which machine (or the global repository) you can do distributed derivation by querying the other machine when you run into something global that you don't know or into other machine's symbols you can't resolve/unify yourself.

This is not a bullet proof concept. There can be infinite loops and it can have really bad performance in some cases. But at least it's something that would be able to do simple corrections and lookups automatically. (E.g. you need temperature in Celsius, but the server stores it Fahrenheit. This is not something that should force you to write code, because we know what temperature means and there are globally available conversions.)

...

Here is something related: https://fenix.tecnico.ulisboa.pt/downloadFile/395145629051/e...

Re: The Future of APIs: APIs aren’t the endgame they won't stay forever

#52

Post by tomc1985 »

EdSharkey wrote: post #45
tomc1985 wrote: post #16

Earlier quoted context omitted.

Tarpit or no, WSDLs are pretty complete interface documentation. It's still weird to me that people see APIs as a "thing", worthy of attention from business types and other nontechnical money-men, And how is it that a "good API" requires client modules for all these different languages? Do people not know how to make HTTP requests anymore or something? (On the client note: "But it makes integration easier" or "I'm la…

> And how is it that a "good API" requires client modules for all these different languages? Do people not know how to make HTTP requests anymore or something? I look at a service like a plate of hors d'oeuvres across the room on a fancy table. A client module (aka SDK) is the silver platter with the hors d'oeuvres neatly lined up for your selection, brought to you by the handsome waiter who is the only other person…

Til you realized those hand-delivered delights aren't particularly well made, and then grumble to yourself about how you coulda made them way better and faster in less time than them, maybe even less time than it would take to eat the food on your plate :P

Re: The Future of APIs: APIs aren’t the endgame they won't stay forever

#53

Post by tomc1985 »

devhead wrote: post #34
tomc1985 wrote: post #16

Earlier quoted context omitted.

Tarpit or no, WSDLs are pretty complete interface documentation. It's still weird to me that people see APIs as a "thing", worthy of attention from business types and other nontechnical money-men, And how is it that a "good API" requires client modules for all these different languages? Do people not know how to make HTTP requests anymore or something? (On the client note: "But it makes integration easier" or "I'm la…

on the client note... code reuse is why these clients exist, if you are a developer I can promise you that you are not issuing tcp requests by hand and instead prefer to use some standard library (curl) to handle that for you.

People don't seem to understand the entire spectrum of consequences that comes with so tightly integrating some cloud service on the other side of the web. That distance is an important detail that these client-gem implementations like to gloss over... because the same developer that reaches for said library may very likely be the same guy to use that gem in some tight inner loop, and then wonder why his app is so slow because get_base_id() has to roundtrip that distance multiple times to answer his question...

Re: The Future of APIs: APIs aren’t the endgame they won't stay forever

#54

Post by lgas »

romaniv wrote: post #51
patkai wrote: post #46

Earlier quoted context omitted.

"distributed Prolog on the global scale. Systems would exchange constraints until they reach a mutually agreeable solution" - wow, I'm impressed, but not sure I fully get this. Any pointers or writeups on this or something similar?

I simply verbalized something that I think is imminently possible. Prolog operates on rules and facts, both of which involve symbols. If you fix the meaning of some symbols globally, you can run queries that will (potentially) derive semantically meaningful information. There is nothing stopping two systems from exchanging rules. If you keep track of which symbol belongs to which machine (or the global repository) yo…

Something like Clojure's spec would allow you to fix the meaning of symbols across one or more cooperating processes without requiring them to actually be global. With an appropriate mechanism for coercions you could even have three cooperating processes work on a solution together where process A and B agree on different (but equivalent) definitions than processes B and C. That sounds really awesome.

Re: The Future of APIs: APIs aren’t the endgame they won't stay forever

#55

Post by tomc1985 »

mattmanser wrote: post #35
kogir wrote: post #18

Earlier quoted context omitted.

.NET and Java had good support for statically generating them (correctly even!) from code, but I never had the pleasure of integrating with such a service. Even in that case though, there were developers who used strings for everything instead of the correct types, didn't handle null correctly, etc. Overwhelmingly in practice people wrote wsdls and xsds by hand, incorrectly, and treated them as secrets instead of pub…

They were a bit of a nightmare. Fun highlights: - IsBooleanPropertyIncludedBoolean - Massive, incredibly slow to build libraries - Check everything in case it was null - Never really sure what was wrong when it went wrong There was quite a massive cognitive overhead and overkill for often querying one little thing. Also they'd sometimes break and you'd have to hand edit the wsdl's to get them to work again (at least…

Well, when correctly implemented, working with WSDLs can be almost pleasant

Re: The Future of APIs: APIs aren’t the endgame they won't stay forever

#56

Post by megablast »

aargh_aargh wrote: post #2

There's an economical problem with the proposed direction of development. API providers are typically businesses or other actors whose interest is to lock the API clients nto their service. What would they gain by making their API interoperable with their competitors? That is only viable for newcomers into the type of service and only works if they clone the API of an established player, not improve on it and standar…

> What would they gain by making their API interoperable with their competitors?

Because it also makes it easier to use those API's, and for people to adopt theirs.

So you will find the better services adopting this first, because they can compete on having a better service.

Re: The Future of APIs: APIs aren’t the endgame they won't stay forever

#57

Post by simonebrunozzi »

romaniv wrote: post #44

As someone who worked on a whole lot of integration projects in the recent past, I think network APIs can be "solved", but not by the means this article describes. JSON-LD looks like a reimplementation of something that was already done by XML, XML Schemas and WSDL. If several technologies that were designed to be semantic failed at automating network API integration, why would you think a sub-format for JSON will su…

Are you... crazy? I would be highly interested in hearing more about this!! :)

Please, please... Write a blog post and tell us what you think. I want to hear it.

Re: The Future of APIs: APIs aren’t the endgame they won't stay forever

#58

Post by EdSharkey »

tomc1985 wrote: post #52
EdSharkey wrote: post #45

Earlier quoted context omitted.

> And how is it that a "good API" requires client modules for all these different languages? Do people not know how to make HTTP requests anymore or something? I look at a service like a plate of hors d'oeuvres across the room on a fancy table. A client module (aka SDK) is the silver platter with the hors d'oeuvres neatly lined up for your selection, brought to you by the handsome waiter who is the only other person…

Til you realized those hand-delivered delights aren't particularly well made, and then grumble to yourself about how you coulda made them way better and faster in less time than them, maybe even less time than it would take to eat the food on your plate :P

Yes, the promised 'delights' are too often frozen plainwrap food from Albertsons, barely defrosted in a dirty industrial microwave.

Re: The Future of APIs: APIs aren’t the endgame they won't stay forever

#59

Post by teilo »

tomc1985 wrote: post #16
teilo wrote: post #7

Can we avoid replicating the tarpit that is WSDL for RESTful services? Time will tell, but I have my doubts.

Tarpit or no, WSDLs are pretty complete interface documentation. It's still weird to me that people see APIs as a "thing", worthy of attention from business types and other nontechnical money-men, And how is it that a "good API" requires client modules for all these different languages? Do people not know how to make HTTP requests anymore or something? (On the client note: "But it makes integration easier" or "I'm la…

> And how is it that a "good API" requires client modules for all these different languages? Do people not know how to make HTTP requests anymore or something?

That is a complex question. For example, our company's ERP is a niche product specific to the printing industry. It has a SOAP API, and a WSDL so large that it will crush any SOAP library that is not doing code generation. We are one of only a handful of their customers who are NOT using their pre-generated SDKs because we do everything in Python and Elixir, and they only provide SDKs for Java, PHP, and .NET.

They rely upon the SDKs to provide API documentation, rather than the WSDL. The CRUD endpoints are consistent and work well - until they don't, and then you have to guess why a call failed due to some undocumented business rule. The process endpoints are a nightmare. Every call is documented as follows: Name, number of parameters. That's it. Parameters are all called IN0 through IN9. There is no documentation specify what the parameters are, which ones are required, what the data types are, or acceptable values/ranges. We have to dig through the SDK code (usually PHP) and make guesses.

To make matters worse, the state-side developers didn't write and don't maintain the API. It's offshored, and any question takes a couple weeks to get answered.

I realize that none of this is SOAP/WSDL's fault. But the fact that the vendor can get away with this shows how many shops really truly can't handle simple HTTP requests, and are hamstrung unless the vendor supplies an SDK. Otherwise the vendor could never get away with this.

As an aside: We ended up writing a REST microservice to translate JSON calls to SOAP for CRUD. (This was also necessary because we discovered that if we did not rate-limit the SOAP calls, the ERP choked). This dramatically simplified our integration code. But to this day, through we have repeatedly requested it, we cannot get full documentation on the process calls.

Re: The Future of APIs: APIs aren’t the endgame they won't stay forever

#60

Post by real-v »

(first post)

Howdy,

This thread is making me consider dusting off a compiler that I wrote for a language that I created for designing APIs. That’s because I strongly agree that lack of versioning in many client/server architectures makes it difficult for devs to evolve their codebases. So, in this language I designed, the versioning of changes is a core concept.

When a server offers an API which can potentially deal with different types of clients, or with clients that need stability, then versioning is a must to have a chance for a sane codebase. Versioning allows the natural evolution of the API, while maintaining compatibility with existing clients.

Out of curiosity, if I were to bring the codebase up to date (C++), and make it downloadable, installable, and usable for free/open-source, maybe for Linux and Windows, would anyone be interested in contributing to a kickstarted for that?

regards,

Vlad

Post reply on HN