3 ms·

This is hardly new... I find odd that people are excited by triviality. The big problem with the micro-API paradigm is the lack of standard. Sure, they might a

This is hardly new... I find odd that people are excited by triviality. The big problem with the micro-API paradigm is the lack of standard. Sure, they might all use REST, but the semantics of the data is highly arbitrary. Take 10 very similar web services with REST APIs, you'll quickly realize that they're all completely different and that you have to learn how to use them one by one. The solution to this is to standarize data, and I believe that the semantic web and linked data is a much superior approach.

smizell 13y ago
Doesn't true REST (not the RPC kind) address these same things when implemented? Content types and hypermedia to allow clients to know how to access the data and follow links to linked data? If we all built our APIs with a registered content type, it would really go a long way for standardizing APIs. Throw in some HATEOAS and you've got standards and links.
- miguelrochefort 13y ago
  You're right. We're still a long way from implementing REST the way it was intented to be. And yes, it is in theory possible to automate conversion using hypermedia and such. However, none of that is going to happen until IDEs let use generate local classes from hypermedia models. There's no reason why I shouldn't be able to select an existing data model (from some popular source, or microformats), and generate a REST endpoint in 1 click. There's no reason for anyone to manually create local classes that mimic these models, code the logic that convert the models in and out, and do a bunch of other manipulations using installed libraries. I just want to select the data, plug it through third-party libraries as a service (online APIs/functions, some of which being open source could be cached locally within the code), and be done with it. We need to be able to reuse everything in a seamless way. Currently, reusing something often means more work and frustration, and most people end up coding their own lesser clones/forks that "does the job". Sigh.
  - smizell 13y ago
    What you're describing has already been done by SOAP+WSDL. Even the term "endpoint" is from the SOAP world, not the REST world. The IDE (usually) does all the heavy lifting of generating and consuming of these endpoints and the developers doesn't have to think about how endpoints are crafted. REST is an architecture that can be implemented in many different ways, so I doubt there will ever be a one size fits all for REST. I think the real win will be when web frameworks allow us to work primarily with resources and representations instead of an MVC architecture.
andrewflnr 13y ago
"They all use REST" in reference to a collection of websites seems like saying, about some people, "they all speak English", even when they might use very different dialects, lingo, and technical vocabulary.
- miguelrochefort 13y ago
  Exactly. They share the same medium, but they don't share the semantics. Learning standard English is an effort we make to communicate more effectively, and I strongly believe that software should do the same thing with data. Just take a look at how software is done. The first step of many project is to define classes, to reinvent the definition of extremely common entities. Why exactly do we need 10000 different classes to represent a "Customer"? Why can't multiple projects share the same "User", "Product", "Student", "Location" and "Transaction" classes? Not only would I not have to reinvent a lesser wheel, but I wouldn't have to explicitly explain how my definition of a "Customer" relates to your definition of a customer. We're just starting to reuse code, thanks to libraries. Why can't we do the same with data models? Now, some might say that their version of a model is better than the standard one. If that's the case, then it would be selfish not to share this improvement with the world, and prevent others from benefiting from this improvement. Simply update the model, and the changes are applied to any software using it. OTA model update done right. "What if someone disagrees with a change?" they say. Well, in moste cases, people will disagree with the cosmetic aspect of a change. They won't like the way something is named, or they will think that some property is superfluous. I can understand that, but that doesn't mean that we should stop there. Can't we just, you know, let people customize their own data UI to match their preference? You don't want to see the 1000000 different properties people thought could be useful to represent an object? Feel free to hide them and use a template that only show you what you care about, such as the Model, Price and Brand. You don't like the term "Brand", and would prefere to call it "Manufacturer"? Feel free to set that synonym as the prefered way to represent this property locally. No need to reinvent the wheel there when we all agree with the semantics of the properties, but simply disagree on cosmetic details. Not unlike a lawyer, the job of a programmer is to communicate effectively and accurately. Vocabulary is a powerful tool that let people communicate potentially complex ideas without having to explicitly define them. If they don't already know what a term mean, they can easily learn it using a dictionary. I believe it makes sense that developers should become vocabulary masters, and learn their way through common data models, as well as common relationships (roles) and actions (functions). A great programmer shouldn't substract a person's birth date from the current date. It should know that this manipulation is called "Age", and simply call the "Age" property (which can be dynamic and calculate its value based on other values, on the spot). Mastering a framework is a great way to become productive. Why can't the framework be universal, general-purpose, and closer to natural languages in term of scope? I mean, we already have dictionnaries that more or less define pretty much anything you would want to represent and/or compute. The code has to be written only once. The second time the code is written, it's wasteful. Unless writting the code is used as a way to search for an unknown term (reverse dictionary). Our culture is plagued by the fear of reuse, by the naivety that everything you think of is novel. Once you realize that most of everything you can think of has already been thougth of before, you start to assume that a solution to your problems already exist, and you start to reuse what others have done. This is the only way to go forward, this is the only way to break through the next abstraction layer. We reached a point where the compiler is no longer the only tool that can save us time (by letting us write higher-level code). We reached a point where reusing what others are working on, in semi-real-time, is the most productive approach. As the web is slowly progressing toward 3.0, programming is just starting to gain the social aspect of the web 2.0. I'm not sure we will ever catch up.

smizell 13y ago

Doesn't true REST (not the RPC kind) address these same things when implemented? Content types and hypermedia to allow clients to know how to access the data and follow links to linked data? If we all built our APIs with a registered content type, it would really go a long way for standardizing APIs. Throw in some HATEOAS and you've got standards and links.

miguelrochefort 13y ago
You're right. We're still a long way from implementing REST the way it was intented to be. And yes, it is in theory possible to automate conversion using hypermedia and such. However, none of that is going to happen until IDEs let use generate local classes from hypermedia models. There's no reason why I shouldn't be able to select an existing data model (from some popular source, or microformats), and generate a REST endpoint in 1 click. There's no reason for anyone to manually create local classes that mimic these models, code the logic that convert the models in and out, and do a bunch of other manipulations using installed libraries. I just want to select the data, plug it through third-party libraries as a service (online APIs/functions, some of which being open source could be cached locally within the code), and be done with it. We need to be able to reuse everything in a seamless way. Currently, reusing something often means more work and frustration, and most people end up coding their own lesser clones/forks that "does the job". Sigh.
- smizell 13y ago
  What you're describing has already been done by SOAP+WSDL. Even the term "endpoint" is from the SOAP world, not the REST world. The IDE (usually) does all the heavy lifting of generating and consuming of these endpoints and the developers doesn't have to think about how endpoints are crafted. REST is an architecture that can be implemented in many different ways, so I doubt there will ever be a one size fits all for REST. I think the real win will be when web frameworks allow us to work primarily with resources and representations instead of an MVC architecture.

andrewflnr 13y ago

"They all use REST" in reference to a collection of websites seems like saying, about some people, "they all speak English", even when they might use very different dialects, lingo, and technical vocabulary.

miguelrochefort 13y ago
Exactly. They share the same medium, but they don't share the semantics. Learning standard English is an effort we make to communicate more effectively, and I strongly believe that software should do the same thing with data. Just take a look at how software is done. The first step of many project is to define classes, to reinvent the definition of extremely common entities. Why exactly do we need 10000 different classes to represent a "Customer"? Why can't multiple projects share the same "User", "Product", "Student", "Location" and "Transaction" classes? Not only would I not have to reinvent a lesser wheel, but I wouldn't have to explicitly explain how my definition of a "Customer" relates to your definition of a customer. We're just starting to reuse code, thanks to libraries. Why can't we do the same with data models? Now, some might say that their version of a model is better than the standard one. If that's the case, then it would be selfish not to share this improvement with the world, and prevent others from benefiting from this improvement. Simply update the model, and the changes are applied to any software using it. OTA model update done right. "What if someone disagrees with a change?" they say. Well, in moste cases, people will disagree with the cosmetic aspect of a change. They won't like the way something is named, or they will think that some property is superfluous. I can understand that, but that doesn't mean that we should stop there. Can't we just, you know, let people customize their own data UI to match their preference? You don't want to see the 1000000 different properties people thought could be useful to represent an object? Feel free to hide them and use a template that only show you what you care about, such as the Model, Price and Brand. You don't like the term "Brand", and would prefere to call it "Manufacturer"? Feel free to set that synonym as the prefered way to represent this property locally. No need to reinvent the wheel there when we all agree with the semantics of the properties, but simply disagree on cosmetic details. Not unlike a lawyer, the job of a programmer is to communicate effectively and accurately. Vocabulary is a powerful tool that let people communicate potentially complex ideas without having to explicitly define them. If they don't already know what a term mean, they can easily learn it using a dictionary. I believe it makes sense that developers should become vocabulary masters, and learn their way through common data models, as well as common relationships (roles) and actions (functions). A great programmer shouldn't substract a person's birth date from the current date. It should know that this manipulation is called "Age", and simply call the "Age" property (which can be dynamic and calculate its value based on other values, on the spot). Mastering a framework is a great way to become productive. Why can't the framework be universal, general-purpose, and closer to natural languages in term of scope? I mean, we already have dictionnaries that more or less define pretty much anything you would want to represent and/or compute. The code has to be written only once. The second time the code is written, it's wasteful. Unless writting the code is used as a way to search for an unknown term (reverse dictionary). Our culture is plagued by the fear of reuse, by the naivety that everything you think of is novel. Once you realize that most of everything you can think of has already been thougth of before, you start to assume that a solution to your problems already exist, and you start to reuse what others have done. This is the only way to go forward, this is the only way to break through the next abstraction layer. We reached a point where the compiler is no longer the only tool that can save us time (by letting us write higher-level code). We reached a point where reusing what others are working on, in semi-real-time, is the most productive approach. As the web is slowly progressing toward 3.0, programming is just starting to gain the social aspect of the web 2.0. I'm not sure we will ever catch up.