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

Implementing Microsoft REST API Filter

sergeykibish.com

Post reply on HN
Print view View original

21–30 of 44 posts

Re: Implementing Microsoft REST API Filter

#21

Post by recursivedoubts »

vxNsr wrote: post #19
recursivedoubts wrote: post #2

don't make me tap the sign: https://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypert... > I am getting frustrated by the number of people calling any HTTP-based interface a REST API. Today’s example is the SocialSite REST API. That is RPC. It screams RPC. There is so much coupling on display that it should be given an X rating. > What needs to be done to make the REST architectural style clear on the notion that…

Hey, I’m kinda new to this area, can you show with examples what the differences are? I read the article, he does a lot of explaining but doesn’t do much showing. Like why is a specific api more RPC and why a different one is a perfectly constructed REST api?

REST was the term Roy Fielding coined as description of the original web architecture. The big distinguishing feature of REST-ful systems vs. non-REST-ful systems was something called the uniform interface, where clients had zero knowledge about a given server's API surface beyond a URL entry point. Everything after that was encoded in hypermedia, giving us the term "Hypermedia As The Engine of Application State" (HATEOAS).

Here is an article I wrote on it:

https://htmx.org/essays/hateoas/

RPC-style APIs require shared knowledge about a given end point: what arguments it expects, what data it returns, etc. Unfortunately, for historical reasons, we've come to call all HTTP JSON APIs "REST APIs". It's actually pretty funny.

Re: Implementing Microsoft REST API Filter

#22

Post by Lazare »

recursivedoubts wrote: post #2

don't make me tap the sign: https://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypert... > I am getting frustrated by the number of people calling any HTTP-based interface a REST API. Today’s example is the SocialSite REST API. That is RPC. It screams RPC. There is so much coupling on display that it should be given an X rating. > What needs to be done to make the REST architectural style clear on the notion that…

One suggestion I've seen (eg here: https://cloud.google.com/blog/products/api-management/unders...) is to distinguish between REST and OpenAPI designs.

Because you're right, REST is a specific thing, but we do need some name for what everyone is talking about, and just saying "RPC" is much too vague.

Re: Implementing Microsoft REST API Filter

#23

Post by ben_jones »

nightpool wrote: post #8
deathanatos wrote: post #6

Earlier quoted context omitted.

… and it's not just the hyperlinking that's problematic. (Yeah, MS's unRESTful "RESTful" APIs do a huge amount of coupling in the form of URL building.) E.g., in Azure, which is also a "RESTful" API that has no idea what REST is about, MS completely misses Fielding points that most of the effort of definition should be spent defining the content / data's format, not things like URL structure. That way we can speak ab…

I'm not sure how you're blaming JSONSchema for "Half the fields in the type will be required … and the schema will say they're optional". But JSONSchema has plenty of ways to define sum types: http://json-schema.org/understanding-json-schema/reference/c...

Am I right to call out most of this problem is caused by incessantly reusing types (because defining an additional type for i.e. CREATE vs PUT actions is soooo hard.

Re: Implementing Microsoft REST API Filter

#24

Post by AlphaSite »

XVincentX wrote: post #9
deathanatos wrote: post #6

Earlier quoted context omitted.

… and it's not just the hyperlinking that's problematic. (Yeah, MS's unRESTful "RESTful" APIs do a huge amount of coupling in the form of URL building.) E.g., in Azure, which is also a "RESTful" API that has no idea what REST is about, MS completely misses Fielding points that most of the effort of definition should be spent defining the content / data's format, not things like URL structure. That way we can speak ab…

Disclaimer: I work for Microsoft as an API Architect. I am not working on this specific API, so I am not going to comment on anyway. I hear your complains about Microsoft API guidelines (which is an entire different conversation) but I wanted to add my two cents with regards to JSON Schema. The problem that I have been having with JSON Schema since forever - is that the data that is being modeled is complected with c…

I’ve debated back and forth on whether it’s a good idea to have separate input and output models for each endpoint, because trying to have a generic structure that’s usable everywhere makes it really easy to pipe output back to input for a PUT, but it’s difficult to express constraints like, this field cannot be updated, only created or these fields are required but only for create and update supports a different subset of the fields again.

I think ideally you want seperate structures but you need tooling which helps you map between output/input structure automatically (in strongly typed languages, it’s easy in Python or JavaScript) and that’s just lacking currently.

Re: Implementing Microsoft REST API Filter

#25

Post by qxmat »

I did the same a while back.

I used ANTLR4 to generate a .NET tree walker that would build up an IQueryProvider expression. IQueryProvider would then compile to Expression and self-optimise (simplifying boolean algebra and removing redundant expressions). We hooked this up to npgsql and viola - a sane, typesafe, query string DSL without a single line of SQL.

Nowadays I hack together Terraform and Python ML- I miss .NET dearly... it was a simpler time.

Re: Implementing Microsoft REST API Filter

#26

Post by lliamander »

recursivedoubts wrote: post #20
derefr wrote: post #18

Earlier quoted context omitted.

A true REpresentational State Transfer API would give each version of each of the API's L7-protocol request and response messages its own media-(sub)type; and would then rely on HTTP content negotiation to allow clients to specify which messages they're expecting to receive in response to a request; where the difference between throwing/nonthrowing, sync/async, new/old variant, etc., would all come down to which resp…

no, the whole media type thing was a moderately-interesting-idea-turned-ridiculous-navel-gazing turn that, among many other pedantic blind alleys, turned everyone away from the deeply innovative aspect of REST: the uniform interface, and, in particular, HATEOAS https://htmx.org/essays/hateoas/ any idiot (such as myself) who has ever made a web 1.0 app has created a better REST API than 99.9% of all REST API engineers…

I have created Hypermedia APIs using HTTP/JSON for service-to-service interactions, and it is definitely a lot of work for questionable benefit.

The biggest problem with the bad style of RPC-style programming was the assumption that remote calls could be treated like local calls. Modern HTTP-based RPC APIs don't make that assumption and thr problems of distributed computing are handled explicitly.

The semantics of HTTP verbs, semantically meaningful namespace trees for resources in the URL, standard authentication and encoding, etc are all nice benefits of HTTP APIs even without hypermedia.

That said, I haven't given up on hypermedia APIs! I liken them to "fluent" APIs of OOP. It's a powerful design approach, but I just wonder how to capture the benefits of that approach over what most people are doing today.

Re: Implementing Microsoft REST API Filter

#27

Post by criddell »

recursivedoubts wrote: post #2

don't make me tap the sign: https://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypert... > I am getting frustrated by the number of people calling any HTTP-based interface a REST API. Today’s example is the SocialSite REST API. That is RPC. It screams RPC. There is so much coupling on display that it should be given an X rating. > What needs to be done to make the REST architectural style clear on the notion that…

Why isn’t the meaning of REST allowed to drift? In the comment section of that page Roy mentions how the meaning of hypertext has drifted over time. Why shouldn’t REST evolve as well?

Re: Implementing Microsoft REST API Filter

#28

Post by lliamander »

lkxijlewlf wrote: post #5
voidfunc wrote: post #3

Earlier quoted context omitted.

You can tap the sign as much as you want, that battle was lost a long time ago. REST is just the common term people use for HTTP+JSON RPC.

"Ugh... REST is too much work! We'll just change the meaning to suit us."

Why should people do hypermedia if it is too much work?

The Web (the prototypical REST application) had a lot of good ideas, not just hypermedia. It certainly makes sense to attribute those good ideas to REST.

Re: Implementing Microsoft REST API Filter

#29

Post by zamalek »

recursivedoubts wrote: post #2

don't make me tap the sign: https://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypert... > I am getting frustrated by the number of people calling any HTTP-based interface a REST API. Today’s example is the SocialSite REST API. That is RPC. It screams RPC. There is so much coupling on display that it should be given an X rating. > What needs to be done to make the REST architectural style clear on the notion that…

REST isn't REST anymore. Barely anyone does it "correctly." The term has gained an overload: anything that happens over HTTP that OpenAPI is likely able to describe.

REmote Structured Transactions. Problem solved.

Re: Implementing Microsoft REST API Filter

#30

Post by jackling »

recursivedoubts wrote: post #21
vxNsr wrote: post #19

Earlier quoted context omitted.

Hey, I’m kinda new to this area, can you show with examples what the differences are? I read the article, he does a lot of explaining but doesn’t do much showing. Like why is a specific api more RPC and why a different one is a perfectly constructed REST api?

REST was the term Roy Fielding coined as description of the original web architecture. The big distinguishing feature of REST-ful systems vs. non-REST-ful systems was something called the uniform interface, where clients had zero knowledge about a given server's API surface beyond a URL entry point. Everything after that was encoded in hypermedia, giving us the term "Hypermedia As The Engine of Application State" (HA…

Thanks! I was really confused with this topic, and your post cleared things up. But from what I gather, proper REST API's wouldn't pair nicely with modern day UI development. Maybe this is because I usually work with APIs that wouldn't be considered restful (from my understanding, my company's public API is here [https://developer.veevavault.com/api/22.1/]), I have a hard time seeing how a modern React webapp would parse the HTTP form response given in your article.
Post reply on HN