6 Easy Tips to Design an AWESOME REST API

I'm looking forward to see more videos about the design. Like general concepts. I learn all programming by myself and after a short period of time I realise, that I'm developing a Frankenstein that's gonna eat me in a while. I build mess 😂

This video came at just the right moment. Preparing some API s for a system, these tips will be implemented immediately. Thanks Arjan.

This was just an excuse to bash the PayPal API, wasn't it🤣

not a great thumbnail

I never actually succeeded to do anything in SQLAlchemy from their documentation 😅

Always looking forward to Friday 17 CET

Standards and Easy integration are probably the most important. For example, if an API is going to accept a standardized data format (like JSON), FOLLOW THE SPEC!! (Authorize Net, I'm looking at you!!)

You read my mind. I had been thinking about finding resources on what a good API should be

APIRoast 🔥

Excelente tips!
👏👏👏👏👏

Hi Arjan, your videos are as always precise and insightful.
I have a question: I am currently doing a project that requires at the end of the execution to push 20-25K rows of data mssql server (on premise). I used sql alchemy, was bit slower. later I used pyodbc, bit faster. Now approx. it takes 3 minutes to push 4k rows. My data has 20 columns, including int, varchar, and bit types.

Would you suggest something, that could make the pushing faster, maybe each time with a chunks of 100-150 rows?

We need a video to learn how to develop the SDK, please

Thanks! This is was great coverage of the subject.

@ArjanCodes Thanks for the video. I have two questions: 1. What do you think about swagger for api documentation?
2. How do you like to use POST instead of GET in case of multiple search filters?

What about making a test framework / sandbox for unit testing your API?

Anyone watching this video, ignore all of Arjan's comments on Paypal's use of ISO-8601 datetime format. That is a financial and developer centric API, so it requires arguments to be *as accurate as possible*. The use of the ISO format:
- Guarantees an international standard
- Guarantees easy datetime parsing and construction in almost all modern programming languages (python is one of the few oddballs that didn't follow international standards on datetime strings for some daft reason)
- Guarantees cross time zone accuracy

While Arjan is correct in saying arguments in APIs should be simple and easy to use, this is one of the worst examples to give! Datetimes in financial transactions are just one of those things where accuracy is a pivotal Functional Requirement

The fact that you write applications that don't care about proper representation of time is just an admission that you don't actually work in the real world. Using anything other than a proper standard representation of time in a api that is used globally would be crazy. Somtimes things are not as simple as it is with your hobby projects.

re: datetimes and "Internet Time", datetimes are tricky but are you proposing to use something else than iso8601? Or is your point just that they weren't clear about which format?

I suppose "Internet Time" is not common, it did not ring a bell to me, but ISO 8601 would immediately :D. Personally I lean towards thinking that UNIX timestamps are the easiest, on the other hand I have never really confirmed this. (ISO 8601 has the advantage that you can understand or write it---if you're nerdy enough--by hand.)

Great video ! But clearly you didn't design your api to handle a couple of trillion concurrent requests ! What is this ?!? Amateur hour ?

Apparently there is `sqlalchemy-json` project that adds mutation-tracked json types.

I know private methods isn't a really python thing but I would have used the _ naming convention for methods I'll use only inside the class.

Very insightful video!

The time/date standards are complicated but are handled in the base library in Python plus additional packages (probably the same for js). There are a lot of transactions so requiring seconds is probably a performance issue.

PayPal documents that it has a delay of up to three hours between something being entered and appearing in the search results. You don’t mention the other handlers. Do they explicitly say the response is instant (or has some shorter period)? Or are you assuming that their lack of statement means that it is immediate? Have you tested them? Are you truly this naïve?

Hmmm.. I didn't get the part with adding ids of related object. Isn't that obvious that You should provide only needed data (it means that related objects will be usefull only for chosen use cases) ? And then, when it's needed You can always return not only ids but also aggregate (more detailed information about related objects) . Input and output serializers (or input and output dto's) are also next big thing You missed. I liked that you showed real API's examples.

Thanks, Arjan!

You’re a legend! Pointing out which APIs are great vs. sht is so helpful

Stupid Question- what is difference between documentation and SDK?

I can see why PayPal API would be intentionally designed to force use of fully granular arguments re: datetime (including seconds and timezone). It's an interesting pivot point here between "keep it simple" and "use obvious default behavior" vs safeguard the user against dumb logic errors especially where there are possible gotchas. (How you handle datetimes is a classic source of headache.)

But this actually serves your broader point -- it should ALWAYS be as simple as possible. There should be a good reason why it's not as simple as you might think at first. And that reasoning should be explained well, and made obvious through example code. AKA "as simple as possible" might not mean "as easy as the novice thinks of it", and the required complexity then needs to be surfaced directly.

I see a lot of sites providing a panel with example for various languages (cURL, Python, JS, ...) as input and corresponding result for every endpoints.
Is there a way to generate this panels automatically?

While that all nice and dandy, I have a felling that some basic CRUD must be "out-of-the-box" experience.. like plug in your custom functions here and there and get an API (is there a package like that? gotta be somewhere..), at least for CRUD on objects that customer "owns".

Thanks for the video. I enjoyed it !

Quickly becoming the best coding channel. $10 for pro is too little I think its worth more than that. You should add supporter their for more than 10 I would get it in a heartbeat the value is already there.

It would be interesting if you created a video or course about structuring a fastapi application. E.g, how would you structure the endpoints (model-focused? domain focused?), how would you handle business logic?

Thanks Arjan!

I think you use “Mea culpa” wrong Arjan. Look it up.
Video is good info though, even for when you don’t write Python.

I like your channel, the content and your preesentation and talking. Its a lovely channel. But the pictures before you click the video, are terrible. Really really bad. Please improve that, a litle bit more classy ;)

Throughout the years I have found that the use of any pattern/technique/solution/method/etc., is using it in the right context. That is, use common sense, that is what people lack (including coders and programmers!)

You don't have to use a bulldozer to dig a 1 meter deep hole, you can use a shovel and it will work like a charm. But if you expect do dig a foundation with a shovel it will take forever! Use the right tool for the right context!

The naming of a member function "dict" made me shudder in the shadows.
Really useful video though. I've been trying to wrap my head around how to make an api for a complex embedded sensor with an existing code base.
Not sure if this is something you can help out with in general; adding an API to an existing project which is normally configured by a config file (or ENV) that only gets read on startup.
Cheers!

god bless you Arjan. thanks a lot for your work.