3 ms·

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 an

by 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.

by smizell 13y ago

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.