Dylan Beattie is at the top of my list of technical presenters. He is probably the most informative and interesting to listen to, alongside being very entertaining. Honestly almost all of his presentations are masterpieces.
If you're in a hurry, you shouldn't build a truly hypermedia REST, that's true, but what you should still do is to design the system so that it can evolve to become more RESTful with as little disruptions as possible, within the time constraint that you do have. While it's great to have a fully hypermedia API out in version 1, in many cases you have to progress towards REST incrementally. When designing your API, always think what parts of the current design will become impediments towards progressing the API towards REST. There are many easily avoidable design mistakes that can make your progress towards RESTful Hypermedia API unnecessarily harder. Know them, learn them, and try to avoid them when you can. This is a tech debt. Sometimes you have to take shortcuts and violate one of REST constraints. If you do, make sure you have an exit plan in mind, so you know what you'll need to do when you're ready to implement the constraint that you skipped.
The song at the start is brilliant... I wish I had a nicely recorded copy 'cus it "touched my soul" ;) In a world where "well delivered talk" is a RARE compliment.... Well delivered talk!
"Do I want my session time to be set to an hour? Do I want my session time to be set to five minutes?" Or do I want my session time to be set to the PHP default of 24 minutes, because the default session time constant was assuming the time would be measured in minutes but actually it was measured in seconds, so it was intended to be 24 hours? ;)
This idea of "hypermedia" blows my mind and not in the way you'd think. We have "hypermedia formats" now that are nothing but a few conventions on how to name stuff in JSON files? In case that's what that song in the beginning refers to... yeah, we are making our own framework because we don't want to choose. We'll come up with identifiers in data files ourselves thank you very much.
Doing everything yourself in your corner is fine until you want to collaborate and interoperate with arbitrary third parties, and hope to remain relevant, consistent and understandable for a long time. The idea of having a public, standardized ontology for what names mean in specific contexts, is so that semantics of data become explicit and machine readable. Imagine building a crawler that goes and accesses random APIs to look for some specific information in various resources. Like crawling different social medias, or ecommerce inventories, or scientific databases. Unless the APIs specify something like a json-ld context with explicit semantics for attributes, your crawler can't know what to look for ("name", "fullname", "firstname", "alias"?) and whether the same attribute name means the same thing across APIs. It's a powerful concept to be able to automatically process and understand data in a global context. You can go search and read about linked data and the semantic web to get a better idea about this.
29:50 There be dragons here. If a user's name is numeric, this URL scheme doesn't give you a nice way to know whether /profiles/84 refers to the hero named 84 or the record with ID 84.
53:00 ... Weelll ... I see the point. But the universality of the answer depends on stuff. If you insist that v2 must always be the same code base, you kinda rule out all situations where you decide to change programming language for v2. But who would also do that? ... PHP works fine.
Hmm... regarding 27:30 ... pagination. This does not support the client and server agreeing about state. Especially not if there's ordering to the items. You'll need something like WedDAV sync-token.
- hey guys xml is too complex and bloated, look at our new simple json! - but it can't even store date and time - hey we fixed that - but how do I validate it? ... couple more iterations later: json-ld, hydra, odata and all others monstrosities appear on the stage
I don't get the fuzz. All of them are just a few simple rules on formatting data. Just pick what suits your needs or cook something up yourself. Especially those "hypermedia formats". It's not even formatting rules, it's just a bunch of names for stuff. And apparently there's organisations that make websites about what "name" means in their "hypermedia format". Give me a break.
Dylan Beattie is at the top of my list of technical presenters. He is probably the most informative and interesting to listen to, alongside being very entertaining. Honestly almost all of his presentations are masterpieces.
Bryan Cantrill, too.
Yesterday I watched half of this video. Today I’ll finish watching the rest of the rest of REST 😉
Stop 😭😭😭
You took a rest before the rest of the rest of rest
@@MilesFlavel Oh the puns… please give it a rest!
In a restaurant ?
@@eccomi21 Why so much unrest ? ;D
If you're in a hurry, you shouldn't build a truly hypermedia REST, that's true, but what you should still do is to design the system so that it can evolve to become more RESTful with as little disruptions as possible, within the time constraint that you do have.
While it's great to have a fully hypermedia API out in version 1, in many cases you have to progress towards REST incrementally. When designing your API, always think what parts of the current design will become impediments towards progressing the API towards REST.
There are many easily avoidable design mistakes that can make your progress towards RESTful Hypermedia API unnecessarily harder. Know them, learn them, and try to avoid them when you can.
This is a tech debt. Sometimes you have to take shortcuts and violate one of REST constraints. If you do, make sure you have an exit plan in mind, so you know what you'll need to do when you're ready to implement the constraint that you skipped.
The song at the start is brilliant... I wish I had a nicely recorded copy 'cus it "touched my soul" ;)
In a world where "well delivered talk" is a RARE compliment.... Well delivered talk!
He's got it on his channel! ruclips.net/video/Wm2h0cbvsw8/видео.html
I had 2 attempts at building REST API and both of them were unsuccessful. Now I see why. I really missed the rest of the REST :)
This is better then any university lecture I have sat through
"Do I want my session time to be set to an hour? Do I want my session time to be set to five minutes?"
Or do I want my session time to be set to the PHP default of 24 minutes, because the default session time constant was assuming the time would be measured in minutes but actually it was measured in seconds, so it was intended to be 24 hours? ;)
Great summary of problems related to REST, thanks for that
This idea of "hypermedia" blows my mind and not in the way you'd think. We have "hypermedia formats" now that are nothing but a few conventions on how to name stuff in JSON files? In case that's what that song in the beginning refers to... yeah, we are making our own framework because we don't want to choose. We'll come up with identifiers in data files ourselves thank you very much.
Doing everything yourself in your corner is fine until you want to collaborate and interoperate with arbitrary third parties, and hope to remain relevant, consistent and understandable for a long time.
The idea of having a public, standardized ontology for what names mean in specific contexts, is so that semantics of data become explicit and machine readable.
Imagine building a crawler that goes and accesses random APIs to look for some specific information in various resources. Like crawling different social medias, or ecommerce inventories, or scientific databases. Unless the APIs specify something like a json-ld context with explicit semantics for attributes, your crawler can't know what to look for ("name", "fullname", "firstname", "alias"?) and whether the same attribute name means the same thing across APIs.
It's a powerful concept to be able to automatically process and understand data in a global context.
You can go search and read about linked data and the semantic web to get a better idea about this.
So... basically...
What GraphQL was trying to fix in REST was actually there all along 😂
video starts at 4:10
29:50 There be dragons here. If a user's name is numeric, this URL scheme doesn't give you a nice way to know whether /profiles/84 refers to the hero named 84 or the record with ID 84.
53:00 ... Weelll ... I see the point.
But the universality of the answer depends on stuff.
If you insist that v2 must always be the same code base, you kinda rule out all situations where you decide to change programming language for v2.
But who would also do that? ... PHP works fine.
Hmm... regarding 27:30 ... pagination.
This does not support the client and server agreeing about state. Especially not if there's ordering to the items.
You'll need something like WedDAV sync-token.
I loved that song
Is there the raw song at the beginning somewhere I can listen ?
Edit: my bad I found it: ruclips.net/video/Wm2h0cbvsw8/видео.html
409 conflict? ... Assuming you use etags or last-modified, wouldn't you rather see a 412 precondition failed?
- hey guys xml is too complex and bloated, look at our new simple json!
- but it can't even store date and time
- hey we fixed that
- but how do I validate it?
...
couple more iterations later:
json-ld, hydra, odata and all others monstrosities appear on the stage
Pretty sure it's still better than XML
@@KManAbout So far. XML didn't blow up overnight. But... pretty sure it's better than EDI
I don't get the fuzz. All of them are just a few simple rules on formatting data. Just pick what suits your needs or cook something up yourself. Especially those "hypermedia formats". It's not even formatting rules, it's just a bunch of names for stuff. And apparently there's organisations that make websites about what "name" means in their "hypermedia format". Give me a break.
When does last mean penultimate?
API Versioning: ruclips.net/video/g8E1B7rTZBI/видео.htmlm43s
intro song has poor audio quality because copyright?
nice
This Video has way too few likes! 👍
The worried icebreaker indisputably disappear because bait intralysosomally sprout pro a muddled saturday. violent, offbeat digital
The arrogant tone makes it unwatchable.
Dylan's not arrogant. That's just the tone of his voice.
The useless roll electrophoretically tick because joseph sadly grin absent a parsimonious expansion. weak, wretched amusement