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

Designing and building RESTful APIs isn’t easy. On its surface, it may seem simple - after all, developers are only marshaling JSON back and forth over HTTP, right? Believe it or not, that’s only a small part of the equation. There are many things to keep in mind while building the systems that act as the key to your system.
In this session, Spencer will delve into several best practices to keep in mind when designing your RESTful API. Attendees will learn about authentication, versioning, controller/model design, testability, documentation and change management. This session will also explore the do’s and don’t’s of RESTful API management so that you make sure your APIs are simple, consistent, and easy-to-use.Examples will be done using ASP.NET Web API and C#. However, this session will benefit anyone who is or might be working on a RESTful API.
NDC Conferences
ndc-london.com
ndcconferences...

[@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.

[@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.

[@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

[@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.

[@joericeulemans1068]

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

[@einfacherkerl3279]

presentation starts at 7:55

[@Zer0n3]

”I’m magic but not that magic” 😆

[@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?

[@sachinkainth9508]

This is really awesome - seriously.

[@ayoubdkhissi]

Great talk! Thank you

[@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 :)

[@knubbigfluffigkatt3972]

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

[@joeljaydurban7918]

Thank you for the great presentation!

[@gabrielpato8841]

Extremely useful stuff

[@shenth27]

Useful stuffs.

[@abdykerimovurmat]

Screamer at 19:16

[@Dereeg]

Great info! Thank you!

[@Toni95N]

awesome talk!

[@B-Billy]

Nice presentation

[@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

[@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

[@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.

[@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.