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

31–40 of 64 posts

Re: Introspected REST: An Alternative to REST and GraphQL

#31

Post by tannhaeuser »

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 tell you that naive REST spaghetti is absolutely much worse than any SOA design ever was. The technical debt and high maintenance might not be apparent while you happily code away your new "microservice"; but I can assure you you've just traded a tiny bit of upfront design for a long-term puzzle you're leaving behind.

Did you know WSDL has supported "REST"-like encoding of parameters in URLs and operations as HTTP verbs since 2001?

Re: Introspected REST: An Alternative to REST and GraphQL

#32

Post by unscaled »

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…

Even assuming we'd want XML as the message/schema format back (with all the security, performance and readability issues it entails), SOAP/WSDL/WS-* was any better than rest in standardization back in the day.

For instance, there were multiple different ways you could format your message (RPC/encoded, RPC/literal, Document/encoded, Document/literal, Document/literal wrapped) and different implementations supported different formats. There were all kinds of extra features that were never supported across board like multi-part messages etc.

Before WS-I there was practically zero guarantee that two SOAP implementations would ever be able to interoperate (and please remember, while REST has no standard in practice, it's dead simple to implement REST by hand - the same couldn't be say about SOAP!). WS-I only came out in 2004 or so, and by then it was already too late. I'd say the SOAP ecosystem is the definitive case study for trainwrecks.

If you really want a standard method for RPC then you're much better off with a modern implementation like gRPC or Thrift or Cap'n proto. Please don't go back to the nightmare called SOAP.

Re: Introspected REST: An Alternative to REST and GraphQL

#33

Post by arnvald »

tinyvm wrote: post #10

I wasn't able to read this entirely it's a very dense spec. That said , even if the arguments in this spec are solid the entire industry are sold itself to GraphQL. GraphQL has won and it won't change.

2007: SOAP has won and it won't change

2012: REST has won and it won't change

2018: GraphQL has won and it won't change

2023: ...

Re: Introspected REST: An Alternative to REST and GraphQL

#34

Post by james_s_tayler »

arnvald wrote: post #33
tinyvm wrote: post #10

I wasn't able to read this entirely it's a very dense spec. That said , even if the arguments in this spec are solid the entire industry are sold itself to GraphQL. GraphQL has won and it won't change.

2007: SOAP has won and it won't change 2012: REST has won and it won't change 2018: GraphQL has won and it won't change 2023: ...

Hahahahahaha.

Perfect.

Maybe 2023: gRPC has won and it won't change

Re: Introspected REST: An Alternative to REST and GraphQL

#35

Post by paulddraper »

philwelch wrote: post #25
paulddraper wrote: post #21

Earlier quoted context omitted.

REST is maximally interoperable and long lived. E.g. you can stick an off-the-shelf caching reverse proxy in front of a server. E.g. you can split data centers and direct your hypermedia links there. I think there are often more important things then just interoperability and flexibility, but those were the guiding principals of REST.

HTTP-JSON—RPC can do this, though. You don’t need the weird hypermedia or pseudo-OO ideas that are usually implied by “REST”; you just need to POST when you need to POST, GET when you need to GET, and set your headers properly. Most of the benefit of REST over SOAP was the fact that it used HTTP correctly instead of implementing a redundant protocol on top of it. Having machine-readable API contracts is still extreme…

Right. HTTP (i.e. REST sans hypermedia) gets you interoperability.

It doesn't get you the "flexibility" of hypermedia/HATEOS, but it depends on your application if you need that. Most projects don't call for 15+ year APIs.

Re: Introspected REST: An Alternative to REST and GraphQL

#36

Post by organsnyder »

unscaled wrote: post #32
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…

Even assuming we'd want XML as the message/schema format back (with all the security, performance and readability issues it entails), SOAP/WSDL/WS-* was any better than rest in standardization back in the day. For instance, there were multiple different ways you could format your message (RPC/encoded, RPC/literal, Document/encoded, Document/literal, Document/literal wrapped) and different implementations supported di…

It's almost like interoperability is hard or something.

Re: Introspected REST: An Alternative to REST and GraphQL

#37

Post by dfox »

unscaled wrote: post #32
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…

Even assuming we'd want XML as the message/schema format back (with all the security, performance and readability issues it entails), SOAP/WSDL/WS-* was any better than rest in standardization back in the day. For instance, there were multiple different ways you could format your message (RPC/encoded, RPC/literal, Document/encoded, Document/literal, Document/literal wrapped) and different implementations supported di…

I feel that the point is not about the transfer representations but about the interaction model. REST makes sense as long as you can sanely map your interactions onto simple modification of something that can be meaningfully described as "resource". For typical application that implements non-trivial bussines processes this means that you either expose low-level implementation details (ie. how you internally represent progress of some process) in your API or you implement "REST" API that is sufficiently far from what REST is supposed to mean that it stops to make sense to use that moniker.

On the other hand SOAP is good match for such applications because it is simply an RPC mechanism, albeit with unnecesarily complex marshalling and transport layers underneath.

Re: Introspected REST: An Alternative to REST and GraphQL

#38

Post by dustingetz »

hermanradtke wrote: post #30
dustingetz wrote: post #18

Earlier quoted context omitted.

This tooling-first approach is basically what we're going for with http://www.hyperfiddle.net/ – the requirements of the killer app are what drives the hypermedia API, the mechanics of which are extremely innovative and weird. One key difference is Hyperfiddle's I/O layer is decoupled from transport, it is not limited to http or client/server, which opens a whole spectrum of I/O configurations with different performa…

This is definitely interesting and I will spend some more time checking this out. This tooling looks more advanced than pretty much anything else out there, but from what I can tell it is a server-side driven approach. I have been trying to imagine what tooling that is client-side first looks like. It should not matter _how_ a server implements something, such as Siren, only that it properly follows the semantics of…

It can be server driven, but it doesn't have to be. It depends where the data is and what the permissible access patterns are and which process is responsible for enforcing them. These days the data that matters is in server-side databases with tightly controlled access patterns so it is pretty weird for the client to be in charge. Hyperfiddle's data protocols are sufficiently abstract to run anywhere in the continnuum of data ownership [1], but so far we've only bothered to implement the parts of it that matter to today-era businesses. Are we thinking about this the same way or have I missed the mark? [1] http://www.dustingetz.com/:urbit-continuum-of-data-ownership...

Re: Introspected REST: An Alternative to REST and GraphQL

#39

Post by dustingetz »

Royalaid wrote: post #23
dustingetz wrote: post #18

Earlier quoted context omitted.

This tooling-first approach is basically what we're going for with http://www.hyperfiddle.net/ – the requirements of the killer app are what drives the hypermedia API, the mechanics of which are extremely innovative and weird. One key difference is Hyperfiddle's I/O layer is decoupled from transport, it is not limited to http or client/server, which opens a whole spectrum of I/O configurations with different performa…

Just would like to say that being able to leverage an immutable DB at work is amazing, just give it a try and value (timestamp) and you can roll back to any point in the dbs history. Has saved so much heartache between debugging and undoing changes

which database?

Re: Introspected REST: An Alternative to REST and GraphQL

#40

Post by Aeolun »

pookeh wrote: post #20
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…

> but the idea was solid, we just need something simpler but with good enough tooling. You mean like GraphQL? ;)

I always used to think it was terrible, just based on the name.

Then I read the actual documentation, and I felt like it was what I had been missing before.

Now I just need to find a decent implementation.

Post reply on HN