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

1–10 of 64 posts

Re: Introspected REST: An Alternative to REST and GraphQL

#5

Post by politician »

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 schemata is accessible through an introspection interface; one suggestion is to use (cacheable) OPTIONS. Clients would transmit their desired MicroTypes to an endpoint using the Accept-Type header.

If I'm reading this correctly, the author is suggesting the clients be allowed to specify the middleware chain used by the server to compose the response data (cf pagination, query, filter MicroTypes), and that these programmable chains are attached to every traditional REST endpoint collection. In one sense, this is an attempt to marry the resolver chain concept from GraphQL into the world of RESTish JSON APIs.

I think you could pull this off only with a dedicated server library because I don't see real world developers using this technique successfully on the current crop of HTTP webserver APIs. There's also the very real performance issues that come up when clients are allowed to control resolution; we see companies using GraphQL in production locking down the ability to do custom queries.

Re: Introspected REST: An Alternative to REST and GraphQL

#8

Post by geezerjay »

pwpwp wrote: post #2

TLDR?

> TLDR?

Some guy tries to make a case regarding web API design by being both overly pedantic and opinionated on what REST is and how everyone is doing it wrond, proceeds to assert that REST done according to the author's opinion is also wrong, and from that point on (which drags through a dozen sections to make) the author presents "a manifesto" which is the author's opinion on how web APIs should be designed and produces a convoluted definition of a strategy that solves nothing but increases complexity.

Some assertions are bafling at best, such as claiming that JSON is somehow not a media type but a message type, which is just wrong. The silliness continues in other baseless assertions such as asserting that developers are not aware that document types such as JSON are used to define JSON-based document formats, or that "Creating a new Media Type for our API is generally considered bad practice", which is just plain wrong, or for some reason conflating the thery part of a URL with the media type which is an assertion that raises some questions.

Re: Introspected REST: An Alternative to REST and GraphQL

#9

Post by oscargrouch »

pwpwp wrote: post #2

TLDR?

For me, its basically to add support for metadata in REST, by using things like JSON-LD to describe the layout of data and be competitive with what GraphQL is offering.

Of course there are a common definition for data and metadata, trying to define a common standard.

It's funny how in the end this will end into reinvent a thing like protobuf, but in JSON, much more verbose, and that can't be read by a human anyway.

GraphQL at least do all this while being human-friendly and allowing to define whats needed 'by hand' or by a machine. (But i also dont think this is a great thing to use if the communication is internal and M2M anyway, but its a great solution to serve some api to a bigger crowd of heterogeneous clients)

Post reply on HN