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

Introspected REST: An Alternative to REST and GraphQL

introspected.rest

Post reply on HN
Print view View original

41–50 of 64 posts

Re: Introspected REST: An Alternative to REST and GraphQL

#41

Post by hliyan »

politician wrote: post #5

It looks like the meat starts at section 9. - Sections 1-8 are a summary of REST, HATEOS, their problems, and reflections on the problem that every endpoint is `application/json` and not something more specific to the intended use case. - Sections 9-11 discuss a variant of REST that doesn't use Media Type differentiation for capabilities, but rather composable nuggets of semantics called MicroTypes. The MicroType sch…

I think the best argument the author could have made is an example. If a proposal like this cannot be illustrated in an example (like it can be done for REST or GraphQL), it's likelihood of adoption is going to be low...

Re: Introspected REST: An Alternative to REST and GraphQL

#42

Post by rtpg »

vbezhenar wrote: post #19

I never understood why people love REST. Just use some kind of JSON-RPC, or something like that. In my experience most of so-called "REST" interfaces are just poorly written RPC. Some people even think that REST means HTTP + JSON. It's extremely rare to encounter a true REST interface with e.g. HATEOAS, proper caching, etc. And if many developers can't utilize technology, probably technology is not good enough to be…

REST aligns _very_ well with CRUD. Most software is, basically, CRUD.

So by saying "we're going to go with REST", you can determine about 90% of your API design more or less instantly, and it rarely gets in the way.

You still have to get your domain modeling right, and sometimes you need to make some extra resources. But you have a design that, basically, works.

Re: Introspected REST: An Alternative to REST and GraphQL

#43

Post by pbreit »

tannhaeuser wrote: post #31

Can we just have back SOAP/WSDL and return to rational design and interoperability, or at least limit "REST" to a web facade? I think after 10-15 years of mucking around with "REST" (or what people think it is, as rightfully pointed out in TFA) it's very clear that there's not going to be a common understanding, let alone standard for it. As a freelancer having worked on maintaining many "REST" trainwrecks, I can tel…

I had to support a SOAP-based API (PayPal v1) and it was horrific.

Re: Introspected REST: An Alternative to REST and GraphQL

#44

Post by whynotminot »

tannhaeuser wrote: post #31

Can we just have back SOAP/WSDL and return to rational design and interoperability, or at least limit "REST" to a web facade? I think after 10-15 years of mucking around with "REST" (or what people think it is, as rightfully pointed out in TFA) it's very clear that there's not going to be a common understanding, let alone standard for it. As a freelancer having worked on maintaining many "REST" trainwrecks, I can tel…

The worst developer hell I've ever been through was fighting through figuring out poorly documented SOAP APIs.

Why the hell would you wish that pain on anyone.

Re: Introspected REST: An Alternative to REST and GraphQL

#46

Post by bjt »

Also submitted a couple months ago. Only got a few comments back then: https://news.ycombinator.com/item?id=15211604

The first sentence of TFA captures one of the most annoying things about REST discussions: "In this manifesto, we will give a specific definition of what REST is, according to Roy, and see the majority of APIs and API specs (JSONAPI, HAL etc) fail to follow this model."

At this point I've read or heard dozens of claims like this, that almost everyone is doing REST wrong. It's well past time to stop blaming all the REST implementers in the world for being too dumb to understand Fielding's brilliant vision. If most software developers can't get REST right, then either proponents have consistently done a crappy job explaining the idea, or it's not as great an idea as they think.

Skimming the table of contents, it looks like the authors have thought deeply about the problems with REST and come up with some well-reasoned solutions. So they're answering the "REST vs Introspected REST" question. But much more relevant to me is the "Introspected REST vs GraphQL" question. What would make someone choose this over GraphQL? Introspected REST has a lot of catching up to do to match GraphQL's tooling and market share.

Re: Introspected REST: An Alternative to REST and GraphQL

#47

Post by tannhaeuser »

whynotminot wrote: post #44
tannhaeuser wrote: post #31

Can we just have back SOAP/WSDL and return to rational design and interoperability, or at least limit "REST" to a web facade? I think after 10-15 years of mucking around with "REST" (or what people think it is, as rightfully pointed out in TFA) it's very clear that there's not going to be a common understanding, let alone standard for it. As a freelancer having worked on maintaining many "REST" trainwrecks, I can tel…

The worst developer hell I've ever been through was fighting through figuring out poorly documented SOAP APIs. Why the hell would you wish that pain on anyone.

> The worst developer hell I've ever been through was fighting through figuring out poorly documented SOAP APIs.

Except for undocumented "REST" APIs with totally arbitrary encodings of parameters into URL path steps and query parms, and needless excessive network roundtrips. Frameworks such as JAX-RS, Spring, and Swagger/Open API even invite you to use "subresources" as out-of-band agreed URL schemes ("lousy coupling"), totally missing the entire point of REST: that you dynamically learn interactions on "resources" via hyperlink URLs as a means for loose coupling.

Re: Introspected REST: An Alternative to REST and GraphQL

#48

Post by eecc »

bjt wrote: post #46

Also submitted a couple months ago. Only got a few comments back then: https://news.ycombinator.com/item?id=15211604 The first sentence of TFA captures one of the most annoying things about REST discussions: "In this manifesto, we will give a specific definition of what REST is, according to Roy, and see the majority of APIs and API specs (JSONAPI, HAL etc) fail to follow this model." At this point I've read or heard…

Well the problem with revolutionary (take this adjective literally) ideas is that most other won’t understand their essential differences and bend them back into familiar perspectives.

In the case of REST, it has been mistreated as SOA-WS for JSON or an RPC for SPAs... hardly anyone bothers with res links.

I would add that hardly anyone bothers with rdf json, while hurriedly reinventing the XML Schema horror movie ;)

Re: Introspected REST: An Alternative to REST and GraphQL

#49

Post by tannhaeuser »

pbreit wrote: post #43
tannhaeuser wrote: post #31

Can we just have back SOAP/WSDL and return to rational design and interoperability, or at least limit "REST" to a web facade? I think after 10-15 years of mucking around with "REST" (or what people think it is, as rightfully pointed out in TFA) it's very clear that there's not going to be a common understanding, let alone standard for it. As a freelancer having worked on maintaining many "REST" trainwrecks, I can tel…

I had to support a SOAP-based API (PayPal v1) and it was horrific.

OTOH, I've worked with EBICS and other ISO 20012 stuff, and while very intense and XML-heavy, it felt like adequate and robust in a way that JSON and schemaless simply doesn't for the task at hand (talking about representing very complex inter-banking businesses on stocks/derivatives with multi-leg deals, foreign exchanges and currencies, IBANs, ISINs, sub-second trading dates, etc.). Even used SOAP/MTOM in 2017, and it worked well enough.

Re: Introspected REST: An Alternative to REST and GraphQL

#50

Post by tannhaeuser »

rtpg wrote: post #42
vbezhenar wrote: post #19

I never understood why people love REST. Just use some kind of JSON-RPC, or something like that. In my experience most of so-called "REST" interfaces are just poorly written RPC. Some people even think that REST means HTTP + JSON. It's extremely rare to encounter a true REST interface with e.g. HATEOAS, proper caching, etc. And if many developers can't utilize technology, probably technology is not good enough to be…

REST aligns _very_ well with CRUD. Most software is, basically, CRUD. So by saying "we're going to go with REST", you can determine about 90% of your API design more or less instantly, and it rarely gets in the way. You still have to get your domain modeling right, and sometimes you need to make some extra resources. But you have a design that, basically, works.

I disagree that most apps are CRUD. To the contrary, most apps starting out as naive CRUD have complex implicit constraints related to eg. in what state you can modify resources in a particular way.

Even for CRUD apps with simple master/detail data relationships it doesn't make sense to tie your domain design to network requests.

Post reply on HN