Fine. They are not actually RESTful. But does it actually matter?
Most RESTful APIs aren't really RESTful
521–530 of 580 posts
Re: Most RESTful APIs aren't really RESTful
#522Earlier quoted context omitted.
This is more like people arguing over "proper" English, the point of language is to communicate ideas. I work for a German company and my German is not great but if I can make myself understood, that's all that's needed. Likewise, the point of an API is to allow programs, systems, and people to interoperate. If it accomplishes that goal, it's fine and not worth fighting over. If my API is supposed to rely on content-…
> I work for a German company and my German is not great but if I can make myself understood, that's all that's needed. Really? What if somebody else wants to get some information to you? How do you know what to work on?
Pretty much everyone speaks English too, it's the official language of the company. Though we all try to be respectful; if I can't understand them then they tell me again in English. I try to respond as much as possible in German and switch to English if needed - there's also heavy use of deepl on my side which seems to be a lot more idiomatic than Google, MS, or Apple translate.
Re: Most RESTful APIs aren't really RESTful
#523Earlier quoted context omitted.
Brb, I'm off to invent another language independent IDL for API definitions that is only implemented by 2 of the 5 languages you need to work with. I'm joking, but I did actually implement essentially that internally. We start with TypeScript files as its type system is good at describing JSON. We go from there to JSON Schema for validation, and from there to the other languages we need.
> Brb, I'm off to invent another language independent IDL for API definitions that is only implemented by 2 of the 5 languages you need to work with. Watch out, OpenAPI is now 3 versions deep and supports both JSON and YAML.
If younger me had been told, "one day kid, you will miss working with XML", I'd have laughed.
YAML made me miss JSON. JSON made me miss XML.
Re: Most RESTful APIs aren't really RESTful
#524It's mostly just semantic drift. "REST" is less of a mouthful than "JSON over HTTP". Nobody ever realised the potential of discoverability.
Re: Most RESTful APIs aren't really RESTful
#525Earlier quoted context omitted.
> I sympathize with the pedantry here and found Fielding's paper to be interesting, but this is a lost battle. Why do people feel compelled to even consider it to be a battle? As I see it, the REST concept is useful, but the HATEOAS detail ends up having no practical value and creates more problems than the ones it solves. This is in line with the Richardson maturity model[1], where the apex of REST includes all the…
> Why do people feel compelled to even consider it to be a battle? Because words have specific meanings. There’s a specific expectation when using them. It’s like if someone said “I can’t install this app on my iPhone” but then they have an android phone. They are similar in that they’re both smartphones and overall behave and look similar, but they’re still different. If you are told an api is restful there’s an exp…
> If you are told an api is restful there’s an expectation of how it will behave.
And today, for most people in most situations, that expectation doesn’t include anything to do with HATEOAS.
Re: Most RESTful APIs aren't really RESTful
#526Earlier quoted context omitted.
Fielding won the war precisely because he was intellectually incoherent and mostly wrong. It's the "worse is better" of the 21st century. RPC systems were notoriously unergonomic and at best marginally successful. See Sun RPC, RMI, DCOM, CORBA, XML-RPC, SOAP, Protocol Buffers, etc. People say it is not RPC but all the time we write some function in Javascript like const getItem = async (itemId) => { ... } which does…
When I realized that I was calling openapi-generator to create client side call stubs on non-small service oriented project, I started missing J2EE EJB. And it takes a lot to miss EJB. I'd like to ask seasoned devs and engineers here. Is it the normal industry-wide blind spot where people still crave for and are happy creating 12 different description of the same things across remote, client, unit tests, e2e tests, o…
My experience is that all of these layers have identical data models when a project begins, and it seems like you have a lot of boilerplate to repeat every time to describe "the same thing" in each layer.
But then, as the project evolves, you actually discover that these models have specific differences in different layers, even though they are mostly the same, and it becomes much harder to maintain them as {common model} + {differences}, than it is to just admit that they are just different related models.
For some examples of very common differences:
- different base types required for different languages (particularly SQL vs MDW vs JavaScript)
- different framework or language-specific annotations needed at different layers (public/UNIQUE/needs to start with a capital letter/@Property)
- extra attached data required at various layers (computed properties, display styles)
- object-relational mismatches
The reality is that your MDW data model is different from your Database schema and different from your UI data model (and there may be multiple layers as well in any of these). Any attempt to force them to conform to be kept automatically in sync will fail, unless you add to it all of the logic of those differences.
Re: Most RESTful APIs aren't really RESTful
#527Earlier quoted context omitted.
> JSON doesn’t really have data types beyond very simple ones What do you think primitive types are supposed to be?
The below type definition (TS) fits the ECMA schema for JSON: type JSON = string | number | boolean | null | JSON[] | {[name: string]: JSON}
You didn't answered my question.
Re: Most RESTful APIs aren't really RESTful
#528Earlier quoted context omitted.
> Fielding won the war It’s a bit odd to say fielding “won the war” when for years he had a blog pointing out all the APIs doing RPC over HTTP and calling it REST. He formalised a concept and gave it a snappy name, and then the concept got left behind and the name stolen away from the purpose he created it for. If that’s what you call victory, I guess Marx can rest easy.
> He formalised a concept and gave it a snappy name, and then the concept got left behind and the name stolen away from the purpose he created it for. I'm not sure the "name was stolen" or the zealot concept actually never got any traction in production environments due to all the problems it creates.
> I'm not sure the "name was stolen" or the zealot concept actually never got any traction in production environments due to all the problems it creates.
That is a false dichotomy. Fielding gave a name to a specific concept / architectural style, the concept got ignored (rightly or wrongly, doesn’t matter) while the name he coined got recycled for something essentially entirely unrelated.
Re: Most RESTful APIs aren't really RESTful
#529Earlier quoted context omitted.
When I realized that I was calling openapi-generator to create client side call stubs on non-small service oriented project, I started missing J2EE EJB. And it takes a lot to miss EJB. I'd like to ask seasoned devs and engineers here. Is it the normal industry-wide blind spot where people still crave for and are happy creating 12 different description of the same things across remote, client, unit tests, e2e tests, o…
My experience is that all of these layers have identical data models when a project begins, and it seems like you have a lot of boilerplate to repeat every time to describe "the same thing" in each layer. But then, as the project evolves, you actually discover that these models have specific differences in different layers, even though they are mostly the same, and it becomes much harder to maintain them as {common m…
anybody ever worked with model-driven methodologies ? the central model is then derived to other definitions
Re: Most RESTful APIs aren't really RESTful
#530Earlier quoted context omitted.
> Brb, I'm off to invent another language independent IDL for API definitions that is only implemented by 2 of the 5 languages you need to work with. Watch out, OpenAPI is now 3 versions deep and supports both JSON and YAML.
If younger me had been told, "one day kid, you will miss working with XML", I'd have laughed. YAML made me miss JSON. JSON made me miss XML.
The pattern I observe is that in old industries, people who paid the cost, try to come up with a big heavy solution (xml, xsd, xpath), but newcomers will not understand the need, and bail onto simpler ideas (json), until they hit the wall and start to invent their own (jsonschema, jquery).
same goes for java vs php/python