We’re an international knowledge based community for API practitioners and enthusiasts. Nordic APIs hosts conferences in Scandinavia and USA, as well as online, that provide expertise and information designed to help organizations become more efficient, automated, and programmable through APIs. Nordic APIs also run a blog, publishing quality API articles twice a week, which regularly are summed up in eBooks free of charge.
For more information about APIs and upcoming events, visit our website and blog - www.nordicapis.com Subscribe to our newsletter - nordicapis.com/newsletter/
Awesomeee! 🙌, but what is the “good way” (or path) to integrate this with common frameworks to couple the code with the spec? (Like express, fastify, etc). Is it to write custom plugins or something like that?
From what I grasped it seems like not a single API I've ever seen meets REST concepts, at the same time the term REST gets throw around all the time. I'm curious about how real frontend and backend systems would be implemented according to described concepts.
Love it. The speaker, should continue being on stage. "A little advice" Lose little of the ascent, just a little. Makes you look a ton more intelligent. Especially at your age. Trust me, and good job
Superb thanks, must add though, you kind of missed the opportunity to crack a great coffee joke, asking to switch a coffee pot on for a fresh brew and receiving a valid 418 error! As defined in rfc2324.
So there are two types of Decentralized Identities, one that is blockchain-based (not even mentioned here) and one that is not blockchain-based. 15:41 The Decentralized Identity systems described here make heavy use of verifiable credential (VCs), and 𝘁𝗵𝗲 𝗯𝗶𝗴𝗴𝗲𝘀𝘁 𝘄𝗲𝗮𝗸 𝗽𝗼𝗶𝗻𝘁 𝗼𝗳 𝗩𝗖𝘀 𝗶𝘀 𝘁𝗵𝗮𝘁 𝘁𝗵𝗲𝘆 𝘀𝘁𝗮𝘁𝗲 𝗲𝘁𝗲𝗿𝗻𝗮𝗹 𝘁𝗿𝘂𝘁𝗵𝘀, but what eternal truth can be said about a person except his/her unique ID, birth date, parents etc? If the VC is a passport with an expiration date D, there is no guarantee that the passport owner won't change his/her nationality before date D. Same goes for name, address, etc. The big advantage of 𝘁𝗵𝗲 𝗯𝗹𝗼𝗰𝗸𝗰𝗵𝗮𝗶𝗻-𝗯𝗮𝘀𝗲𝗱 𝗶𝗱𝗲𝗻𝘁𝗶𝘁𝘆 𝘀𝗼𝗹𝘂𝘁𝗶𝗼𝗻𝘀 (𝘄𝗵𝗶𝗰𝗵 𝗮𝗿𝗲𝗻'𝘁 𝗲𝘃𝗲𝗻 𝗺𝗲𝗻𝘁𝗶𝗼𝗻𝗲𝗱 𝗵𝗲𝗿𝗲) is that data can be updated at any time and the verifier has access to real-time data.
Hahaha! This is hilarious! All these people are listening to someone they think is an "expert" at something when all he's trying to do, is get rid of passwords to sell more Yubikeys. You secure an API with a strong password and proper architecture. There. That saves you from watching a 19-minute veiled advert for Yubikeys.
Claims are metadata about the End user. Scope are authorization limitations for the Client. Both have a purpose and should not be confused (which is easy to do if you only focus on End User Identification extension on top of OAuth2 (OIDC) and not so much on the core OAuth2 purpose of Client Authorization). I prefer to see Scopes as subset Authorzation given to the Client by the End User. I.e allowing a specific client to read your order history but not place new orders on your behalf. Claims are Metadata about the End user.
it works, but not for all cases, in some cases is mandatory to have multiple api version, for example, when a business logic with has a contract with an old app version, both, will work only if they are in the same version.
As a future Docs-for-Devs writer, thanks for this super-helpful presentation! I feel more qualified already. I'm also somewhat star-struck by the Stoplight cameo. `let Stoplight === BestYAMLSlicer;`
X-Road is an open source data exchange layer solution that enables organizations to exchange information over the Internet. X-Road is a centrally managed distributed data exchange layer between information systems that provides a standardized and secure way to produce and consume services. X-Road ensures confidentiality, integrity and interoperability between data exchange parties. Great :::
I never heard about Borges and the hyperlink but the strange thing is that I did hear several times that it was Cortazar with his book "Rayuela". Ambos escritores Argentinos y amigos
To me hypertext seems more a wheel of the application rather than it’s engine: it provides handles (hrefs), human readable views of the resources, controls to trigger operations (buttons, etc.) The engine is inside the car (the server is the engine). If that’s correct we could ditch the HATEOAS acronym for HATWOA (hypertext as the wheel of the application) or remove all conjunctions to make HWA, or use “driver“ instead of “wheel” for HDA… A rebranding seems in order given every time this key aspect of the technology is discussed people gets embarrassed. Branding is important.
