Never RESTing - RESTful API Best Practices using ASP.NET Web API - Spencer Schneidenbach

[@Tanaka-Buchou]

Awesome presentation! Love how he explained REST API concepts with minimal technical demo! It's the kind of tutorial where you don't need to code along but just watch with a cup of coffee and a note.

[@CollinSchneide]

I love this talk! Being able to explain these effectively is a fruit of a solid understanding of best practices, which is what I strive for.

[@midnightcigarettes8564]

As a beginner API designer, this is a very enlightening talk. Thank you very much sir!

[@rtl6832]

Excellent presentation, well done :) I'm so sick of seeing 101 tutorials and it's nice to see something that digs a little deeper

[@joericeulemans1068]

Thanks Spencer! Definitely learned some things while watching the presentation. That's what I came here for ;-)

[@leakyabstraction]

The most annoying thing I personally encountered while consuming an external API is not documenting the regexes with which they validate the strings in the payloads. How fun is to see your payment flow break (on high value products where each purchase matters) because someone decided that the address string can't contain a comma, or the zip field cannot contain a space. 😆If something is documented, then, however awkward or bad, you can design for it. But not documenting validation rules is basically booby trapping your API. Of course it also teaches you that you should always design for failure while consuming external APIs in your flows.

[@hemanthaugust7217]

the reason why name needs to have a separate api could be that - name may have to be formed depending on some query param (such as language, country, etc). So, if a user doesn't always have a need to get name, when getting customer details, it's okay to have name and customer apis separate. However, if UI always needs name along with all other customer details, then it definitely makes sense to return the name in the same response, and behind the scenes, let the customer api server talk to name api server, get the response and tag it along. So, it completely depends on the usecase, we cannot categorically say that not returning name in customer api is bad.

[@sachinkainth9508]

This is really awesome - seriously.

[@nagautube1]

thanks for the upload, and he gave a simplistic and good presentation , in other terms to sum it up , he did in a KISS way as he mentioned :)

[@Cluedinage]

You mention using a separate DTO for every API method. Does that include every display of a read-only grid? Why add DTOs that are never used except to display rows?

[@joeljaydurban7918]

Thank you for the great presentation!

[@ayoubdkhissi]

Great talk! Thank you

[@Zer0n3]

”I’m magic but not that magic” 😆

[@einfacherkerl3279]

presentation starts at 7:55

[@knubbigfluffigkatt3972]

Unfortunately I seldom have time for proper documentation with our dead lines.

[@gabrielpato8841]

Extremely useful stuff

[@Dereeg]

Great info! Thank you!

[@arenddejong6609]

if you set on evry error 200 that's very nice hackers become fustrated and a little angry because all things say 200 ok they do not know what get's impact so it will become much harder

[@abdykerimovurmat]

Screamer at 19:16

[@shenth27]

Useful stuffs.

[@Toni95N]

awesome talk!

[@MrQ1941]

Ha. Good talk but your Mom can’t be working on an AS/400 unless it’s a forgotten one running in a closet somewhere. Those have been gone since 2005. Press on with REST.

[@B-Billy]

Nice presentation

[@fabiotortorella4546]

The developers who use GET to change info on the server are looking into performance, GET are faster, is just not much private info.. post hide the data a little but still in the request.. bs

[@paulfrischknecht3999]

A *server* hosting an API is supposed to provide a *service* . if you don't make it *simple* you are not *serving* much of a *service* ...

[@arifulislamleeton]

introduce myself my name is Ariful Islam leeton im software engineer and members of the international organization and members of the international telecommunications and employees and investors

[@tenminutetokyo2643]

TLDW

[@laktat]

Versioning is something which should not get that generalized. In my opinion, you should not version your API as it can cause issues in integration and more complex systems. Just try to not version your API at least if not necessary (adding new functionality/fields/methods does not require a new version for example)

[@reversebla3de]

If you say put = update, it means you did not understand what rest is.

[@natfailsyoutube8163]

The presenter did not say that "put = update". Likening two things or giving an example use case does not imply they are equal or interchangeable.