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

21–30 of 64 posts

Re: Introspected REST: An Alternative to REST and GraphQL

#21

Post by paulddraper »

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

Re: Introspected REST: An Alternative to REST and GraphQL

#22

Post by treve »

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.

That sounds like a pretty absurd statement. Can you qualify this further?

Re: Introspected REST: An Alternative to REST and GraphQL

#23

Post by Royalaid »

dustingetz wrote: post #18
hermanradtke wrote: post #16

There is some good stuff in here, but it misses the biggest pain point developers face when trying to make a robust hypermedia API: tooling. There is a lack of tooling on the server side and almost no tooling on the client side. The amount of effort required to serve a RESTful API requires a lot of upfront investment. Then convincing the client developers to take advantage of the hypermedia affordances requires a lot…

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

Re: Introspected REST: An Alternative to REST and GraphQL

#24

Post by felixfbecker »

dpim wrote: post #12

This looks a lot like OData - a REST-ful API standard with schema introspection, patterns for defining and traversing resource relationships, well-defined guidance around mechanics, tooling support. In particular, the "Microtypes" concept resembles how entities work in OData - rich query support for collections (eg. sorts, filters, order by), "expansions" on related resources, even inheritance semantics (ie. being ab…

The fact that OData calls itself not only RESTful, but literally "the best way to REST", while using requests like this:

    GET serviceRoot/People('russellwhyte')/Microsoft.OData.SampleService.Models.TripPin.GetFavoriteAirline()
is an absolute insult to REST and the target developer audience.

https://www.odata.org/getting-started/basic-tutorial/#bounde...

Re: Introspected REST: An Alternative to REST and GraphQL

#25

Post by philwelch »

paulddraper wrote: post #21
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 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 extremely valuable; we just found better ways of doing that.

Re: Introspected REST: An Alternative to REST and GraphQL

#26

Post by [deleted] »

felixfbecker wrote: post #24
dpim wrote: post #12

This looks a lot like OData - a REST-ful API standard with schema introspection, patterns for defining and traversing resource relationships, well-defined guidance around mechanics, tooling support. In particular, the "Microtypes" concept resembles how entities work in OData - rich query support for collections (eg. sorts, filters, order by), "expansions" on related resources, even inheritance semantics (ie. being ab…

The fact that OData calls itself not only RESTful, but literally "the best way to REST", while using requests like this: GET serviceRoot/People('russellwhyte')/Microsoft.OData.SampleService.Models.TripPin.GetFavoriteAirline() is an absolute insult to REST and the target developer audience. https://www.odata.org/getting-started/basic-tutorial/#bounde...

[deleted]

Re: Introspected REST: An Alternative to REST and GraphQL

#27

Post by dpim »

felixfbecker wrote: post #24
dpim wrote: post #12

This looks a lot like OData - a REST-ful API standard with schema introspection, patterns for defining and traversing resource relationships, well-defined guidance around mechanics, tooling support. In particular, the "Microtypes" concept resembles how entities work in OData - rich query support for collections (eg. sorts, filters, order by), "expansions" on related resources, even inheritance semantics (ie. being ab…

The fact that OData calls itself not only RESTful, but literally "the best way to REST", while using requests like this: GET serviceRoot/People('russellwhyte')/Microsoft.OData.SampleService.Models.TripPin.GetFavoriteAirline() is an absolute insult to REST and the target developer audience. https://www.odata.org/getting-started/basic-tutorial/#bounde...

I think this is a bit cherrypicked. The example you're using is a fully qualified bound function. OData support for actions and functions explicitly exist to provide affordances for how to do RPC within OData. You can easily model this API in OData without requiring a function (eg. having a navigation property reference called "favoriteAirline"). Moreover, you can typically invoke functions without a fully qualified prefix (save cases where there is ambiguity).

For the most part, OData does a good job at letting folks opt into complexity, allowing integrators to make full use of APIs without needing to know anything about $metadata, inheritance mechanics, functions, etc.

Re: Introspected REST: An Alternative to REST and GraphQL

#28

Post by dbdjfjrjvebd »

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.

> the entire industry are sold itself to GraphQL.

Which industry? I presume you don't mean software development which has largely ignored graphQL? BTW I speak as an early adopter who has used graphQL in production.

Re: Introspected REST: An Alternative to REST and GraphQL

#29

Post by philwelch »

felixfbecker wrote: post #24
dpim wrote: post #12

This looks a lot like OData - a REST-ful API standard with schema introspection, patterns for defining and traversing resource relationships, well-defined guidance around mechanics, tooling support. In particular, the "Microtypes" concept resembles how entities work in OData - rich query support for collections (eg. sorts, filters, order by), "expansions" on related resources, even inheritance semantics (ie. being ab…

The fact that OData calls itself not only RESTful, but literally "the best way to REST", while using requests like this: GET serviceRoot/People('russellwhyte')/Microsoft.OData.SampleService.Models.TripPin.GetFavoriteAirline() is an absolute insult to REST and the target developer audience. https://www.odata.org/getting-started/basic-tutorial/#bounde...

Semantic URL routing isn’t part of REST.

Re: Introspected REST: An Alternative to REST and GraphQL

#30

Post by hermanradtke »

dustingetz wrote: post #18
hermanradtke wrote: post #16

There is some good stuff in here, but it misses the biggest pain point developers face when trying to make a robust hypermedia API: tooling. There is a lack of tooling on the server side and almost no tooling on the client side. The amount of effort required to serve a RESTful API requires a lot of upfront investment. Then convincing the client developers to take advantage of the hypermedia affordances requires a lot…

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 the Siren protocol.
Post reply on HN