Implementing Microsoft REST API Filter • Hacker News Board

Re: Implementing Microsoft REST API Filter

#41

Post by wizofaus » Wed, Jul 13, 2022, 8:13 PM UTC

criddell wrote: post #27

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?

It has, regardless of what Roy believes - I've never come across any API that calls itself RESTful that fits with his idea of what REST is, nor is it clear what advantages it would have.

Re: Implementing Microsoft REST API Filter

#42

Post by wizofaus » Wed, Jul 13, 2022, 8:24 PM UTC

ben_jones wrote: post #23

nightpool wrote: post #8

Earlier quoted context omitted.

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.

If you've already gone to the length of defining your DTO with 20+ typed fields including comments/annotations etc., why should you need to duplicate it between CREATE and PUT types? PATCH is probably the trickiest one to do cleanly - while I've used the model of "re-use the CREATE type, but all fields are now optional" in the past, I wouldn't actually recommend it, and probably promote proper JSONPatch format instead, the only real disadvantage being that it's a harder to manually construct the request body, which isn't something you should be too concerned about end-users having to spend time doing.

Re: Implementing Microsoft REST API Filter

#43

Post by lliamander » Thu, Jul 14, 2022, 7:00 PM UTC

lliamander wrote: post #40

recursivedoubts wrote: post #32

Earlier quoted context omitted.

https://intercoolerjs.org/2016/05/08/hatoeas-is-for-humans.h...

That basically validates the conclusions I have come to as well. However, I would add that I think you can build machine APIs using hypermedia, but the API contract would different. You would essentially define an OOP API with MIME Types as class definitions. That is partly I think why Toy Fielding put so much emphasis on defining those types. But the real pwer of hypermedia - the ability to change those hypermedia r…

*Roy Fielding. Darn auto-correct.

Re: Implementing Microsoft REST API Filter

#44

Post by ben_jones » Sat, Jul 16, 2022, 3:21 AM UTC

wizofaus wrote: post #42

ben_jones wrote: post #23

Earlier quoted context omitted.

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.

If you've already gone to the length of defining your DTO with 20+ typed fields including comments/annotations etc., why should you need to duplicate it between CREATE and PUT types? PATCH is probably the trickiest one to do cleanly - while I've used the model of "re-use the CREATE type, but all fields are now optional" in the past, I wouldn't actually recommend it, and probably promote proper JSONPatch format instea…

> gone to the length

Right there. Because typing 20 lines of source code should not be an argument for weakening your model layer. Re-use would be great if types were identical between actions, but in the real-world they're not and they accrue subtle differences over time.