Пікірлер

• 
  @danielgilleland8611Күн бұрын

  When I see the acronym HATEOAS, I often think "Aw, they've simply mis-spelled Halitosis."

• 
  @mc4ndr3Күн бұрын

  nobody implements the OPTIONS method so by that definition nobody does REST. also, browsers refuse to support the DELETE method, so everybody breaks REST. most companies are so lost that they have yet to hear of OpenAPI, GET caching semantics, or meaningful, consistent, resource based URL schemes. instead of adopting a binary protocol, they try to shave off bytes by reducing ALL query parameters to single letters and other nonsense. graphql looks neat but at a practical level, most engineering teams fall on their face getting a single REST app into production. this is still an industry of unsanitized, un-ORM'ed SQL queries and architects insisting on using a Redis cache before they hear the first project requirement.

• 
  @herbie_the_hillbillie_goatКүн бұрын

  What was the Question?

• 
  @nihil2501Күн бұрын

  I go for "resourcefulness" often. I think the decent idea there is turning verbs into nouns or in other words recording events as facts; aiding full fidelity of information without duplication.

• 
  @chrisstevens3776Күн бұрын

  SOAP - was an oxymoron. Simple .... 'nuff said. I often wonder how that protocol was invented, every developer I every met hated it the first time they saw it. Although, from memory, it was organisations like IBM that promoted that protocol.

• 
  @chauchau0825Күн бұрын

  Spot on how ppl misuse the term REST API. btw, I think Hypermedia doesn't make any sense at all. It might have well intention but has no real usage in reality.

• 
  @markrosenthal9108Күн бұрын

  It's possible to use a wrench to hammer in a nail. We all tend to fall into to the "Shiny New Tool for Everything" trap. Remember what your dad told you: "Use the right tool for the job".

• 
  @jamesdoescodeКүн бұрын

  Like some of the other commenters here, I've never come across the hypermedia aspect of REST until this video, so thanks for educating me on that. As for whether I'd be adding it into some of the APIs I've built....probably not. For me the main benefit of REST is that it's a very standardized way of fetching and editing resources while also being fairly lightweight. A tool like swagger seems to make an actions section of the response entirely redundant, because realistically all that would ever be is just documentation for the developer consuming the API as they write their client, once it's actually running, the actions would almost certainly be ignored. I can see a potential benefit to having links for paginated results, but in the past I've just had my endpoint take page size & page number as optional parameters. Next and previous links could be a nice touch, but more of a minor convenience feature than anything that actually substantially changes how clients interact with the API.

• 
  @xcoder11222 күн бұрын

  I'm a bit confused. Why is OpenAPI mentioned at the end of a list of REST, GraphQL, and gRPC? OpenAPI is just a description language for REST APIs. It shouldn't even be mentioned once in the entire video.

• 
  @klex39052 күн бұрын

  There are different tools for different jobs.. The statement isn't "REST wasn't the answer. " It just isn't the answer for everything, and never was claimed to be. The semantics don't mean much to me at least.

• 
  @auroraRealms2 күн бұрын

  I see now how Word Perfect died. Everything Novell buys goes up in flames. I used to use Linux SuSE unitl Novell bought it, and compeletly destroyed it.

• 
  @AbNomal6212 күн бұрын

  Martin Fowler should be put where he belongs, that is in the place of someone making money be telling and not doing. And in his statement on definition of REST - well he needs to spend more time in language arts where we learn that definitions change over time.

• 
  @edgeeffect3 күн бұрын

  At work, we've got a 3rd party API that goes one stage further than returning an error message with a 200 code.... it returns NO error message and a 200 code.... even when your request has failed... neat huh?

• 
  @Zuriki0919 сағат бұрын

  Salesforce Marketing Cloud messaging API returns a 200 and success response for improperly formatted mobile numbers and then doesn't send the message!

• 
  @carrion12344 күн бұрын

  i actually implemented the HAL RFC draft for one of our backend APIs to enable HATEOAS. being able to reference related resources in the response, but also giving clients the ability to request the embedding of these resources on the fly turned out to be really useful. but so far i think no client implementation really uses the links to discover actions.

• 
  @adambickford87204 күн бұрын

  I didn't know about stiglers law but i've claimed for years that the person who invented murphies law didn't get credit because something went wrong!

• 
  @erikslorenz4 күн бұрын

  JSON Apis that try to have links and stuff are just the worst lol.

• 
  @andreffrosa4 күн бұрын

  But graphql and grpc can still be rest, they are just middleware to enhance basic http communication. However, they don't really go against the rest principles.

• 
  @wolfblaide4 күн бұрын

  Yeah the issue has always been there's no point to the hypermedia part for most APIs. Nice idea, but impractical, difficult, and pointless. So REST in the IT business world just naturally became about having something better than SOAP to create, update, and read data remotely. I think it's fine to call these kind of APIs REST, or RESTful. Everyone does.

• 
  @martineyles4 күн бұрын

  In most cases the hypermedia is useless, because something will be programmed based on the spec rather than reverse engineering from submitted responses. Links could perhaps be applied if the API is designed to be called by a presentation layer, but that's the only case I can think of where it might have a use.

• 
  @philipoakley54984 күн бұрын

  All very Gödelian ;-) You can't prove Rest within a Rest framework. It's like pure maths arguing with applied maths.

• 
  @netssrmrz4 күн бұрын

  Awesome video. My personal opinion... REST is the dumbest possible solution to the problem of "client code wants to run server code". I feel like we've stepped backwards. Give me RPC with autogenerated client-side proxy stubs so I never have to give a dam about the network implementation. The real solution is not to use HTTP for this kind of IPC. I want a dedicated protocol that web servers can utilise alongside HTTP.

• 
  @davidbuchan29094 күн бұрын

  HAHAHA, we're still using SOAP

• 
  @TheCheD34 күн бұрын

  8:15 I think your cat doesn't like Swagger

• 
  @Dennis-vh8tz4 күн бұрын

  I remember when HATEOS, and hypermedia driven API's in general, were the darlings of framework developers and architecture astronauts; however, even during their heyday it was obvious to me that these ideas wouldn't survive contact with reality - they added a lot complexity (and thus development time and expense) while having little practical benefit for most applications.

• 
  @beofonemind5 күн бұрын

  REST will be around in 15 years .... just like Javascript, we are stuck with it. I don't mind it. I like the ask receive nature of it.

• 
  @alexnoman14985 күн бұрын

  Now if you were to send the "Login" button itself instead of a json saying there should be a button - you get HTMX. It exposes the ability to request HTML elements themselves and layouts them in, which can then request more, different elements. The most web native hypertext solution possible, no protocol negotiation beyond "do you speak HTML". You just get sent the finished button.

• 
  @technolungКүн бұрын

  But muh separation of concerns!!!

• 
  @trudyandgeorge5 күн бұрын

  This advice is superb 👌

• 
  @49riddickful5 күн бұрын

  How my watching went : "what is this guy even talking about, whole world is sitting on top of rest apis..." .... "Oh he's gonna talk about ACTUAL REST" 😂😂😂😅

• 
  @trudyandgeorge5 күн бұрын

  This is a masterpiece

• 
  @Kubu2225 күн бұрын

  8:14 great video, now show your cat please 😸

• 
  @firstlast-tf3fq5 күн бұрын

  I’m one of the few stubborn assholes that still insists on hosting my own email server. However, I do so on a Linode VPS because my home internet hasn’t been the most reliable. Couldn’t send any emails for 3 days last week because of Spamhaus. No explanation given, no evidence I could find of my server having been compromised, nothing. Pain in the ass.

• 
  @RobertFabiano5 күн бұрын

  Background noise: cat in heat or small child? 😂

• 
  @DylanBeattie5 күн бұрын

  You know, I have absolutely no idea. No cats or children on the premises. I didn't even notice that until somebody pointed it out on the recording...

• 
  @roganl5 күн бұрын

  Returning an application error in a 200 response is a valid choice. Why overload the transfer protocol signaling when you can and should handle the application error gracefully, and let the application domain remain loosely coupled.

• 
  @andygarfield65295 күн бұрын

  I’m curious if you intentionally didn’t mention HTMX. Doing HATEOAS with HTML makes a lot more sense to me than doing it with JSON because we don’t need to synchronize client state and server state, considering JavaScript isn’t doing a bunch of element creation. HTMX is great because it extends HTML as a hypermedia beyond just the anchor and form tags. It’s a very simple yet powerful idea.

• 
  @marcelvanLare6 күн бұрын

  Ok , i guess i was working with openApi. Works fine for CRUD. So i will just keep going on.

• 
  @alecclews6 күн бұрын

  I used to weasel my way out of it by using the term "a REST like API'

• 
  @tlacmen6 күн бұрын

  web turned successful: "citation needed" LOL ;)

• 
  @DavidBeaumont6 күн бұрын

  REST for me was always about CRUD and defining the data taxonomy in the URL path. Sometimes you added extra data, sometimes that extra data was trivial to compose so didn't need to be sent. You did whatever made the API as clean and stateless as possible because that is what matters for scaling the backend.

• 
  @lebenebou6 күн бұрын

  this channel is a rare gem

• 
  @NotMarkKnopfler6 күн бұрын

  I've been screaming about this for years. You can pass the majority of parameters on the fricking URL. Or use http post. REST APIs just add more wrapping to the data which needs to be unwrapped. My simple PHP web application was 175 times faster by not having to wrap and unwrap data with JSON. You're just adding more overhead.

• 
  @pavelhoral6 күн бұрын

  Very interesting and well explained summary.

• 
  @LeeSmith-cf1vo6 күн бұрын

  imo hypermedia in APIs is just bloat. If the API is well documented then the links are worthless and the consuming code probably doesn't care. The only thing they do is slow down the response time.

• 
  @bobthemagicmoose6 күн бұрын

  REST lost its meaning for me long ago. Tons of pedants running around trying to define it in different ways has left me thinking: “it’s just an API”

• 
  6 күн бұрын

  I never figured out how to actually consume a REST API. I get links back, but usually these links are formulated in a way where coercing it into a shape that is suitable to be fed back into the HTTP client is a lot more work than just putting the paths in the code instead.

• 
  @neal3214 күн бұрын

  You need to parse the result and display the result dynamically using links, buttons etc. To be able to display the results in a user friendly format you need some sort of directives in the response to specify placement, colour etc. So basically you need to develop your own version of a browser, markup language and css type language. Hint: we already have these things, just use them. Arguing if something meets someones definition of a REST API is a waste of time

• 
  @TwoThreeFour6 күн бұрын

  Aww man, give it a rest will ya 😂

• 
  @adambickford87206 күн бұрын

  The alternative to rest was soap. Once you add HATEOAS, the simplicity advantage of rest evaporates but you still have the lack of tooling.

• 
  @kode4food6 күн бұрын

  My apologies for having anything to do with SOAP

• 
  @Twi1ightFr0st6 күн бұрын

  i build APIs with only GET method without building POST endpoints, and use query params to represent the params passed in, and its simple and works well. just like how unpure function calls can return different results, HTTP GET idempotency doesnt really need to be adhered to

• 
  @elijahbuscho77156 күн бұрын

  But then your request size is pretty heavily limited isn't it?

• 
  @Twi1ightFr0st6 күн бұрын

  @@elijahbuscho7715 yes agree with you, I havent build any file upload endpoints yet, that's better suited with POST endpoint and formdata object

• 
  @zBrain06 күн бұрын

  It is interesting to hear the history of the term. I think it has become basically synonymous with anything that uses HTTP verbs, and very often Json payloads. I didn't realize the original definition specifically included hypermedia. Interesting though to see the rise of htmx in the last year or so. I don't think it's for me, but it definitely swings back towards the use of hypermedia directly across the network.

• 
  @EvenTheDogAgrees6 күн бұрын

  I'll be the weirdo here, but personally, I never really liked REST APIs. They're good for simple objects and CRUD operations only, but any time you try to represent something that doesn't fall within that realm, you're producing kludgy nonsense. Personally I'm more of a fan of RPC over REST.

• 
  @luckiydiot6 күн бұрын

  You're not alone :) BTW, another thing I don't like about REST APIs that they tend to push business logic to the frontend. And the languages we use on the frontend (practically, JS) are usually not really a solid choice to implement business logic...