One way that I personally like to allow for more expressive and natural APIs is to leverage the ternary operator, which may sound funny. How does that work? Well, let me give you a few examples, and you can consider these for your own projects. Imagine you have some kind of method in your project, maybe deactivate, and you need to give it a when date. Now, presumably, as part of calling this method, you would update your users table or your subscription table, and you would set their subscription end date to this timestamp. And that's useful. And especially for the purposes of testing, that can be useful. But what if you want the default to be right now? If I say, for example, user deactivate, I shouldn't have to call a method. It should just work immediately. Or I could pass in a timestamp, like three weeks from now, I want to deactivate them.

for example, User deactivate, I shouldn't have to call a method. It should just work immediately. Or I could pass in a timestamp, like three weeks from now, I want to deactivate them. So notice we extend the API while still allowing it to default to something as simple as this. Okay. For that, you would just do something like when equals whatever you gave us or now. And you may not have ever thought about it, but this is, it's just the ternary operator. It's the same as saying, if some var evaluates to true, then do this, otherwise do that. All we're doing here is we're taking this first part, and we're omitting it. And when we do that, it's assumed that this value is what's being returned. Pretty cool. So now we can say when is entirely optional, and then we'll go from there. Okay. How about another example? Maybe you have a method to get a Stripe customer. So this would

So now we can say when is entirely optional, and then we'll go from there. Okay. How about another example? Maybe you have a method to get a Stripe customer. So this would fetch not your User object, but your StripeCustomer object from their API. And this is going to be the exact same thing where we need a customerId to perform the query or the curl request. Now it's possible that you want to default to getting this ID, maybe like off your authenticated user, however you want to do that, something like that, if that's where it's stored. However, when you're writing a test, sometimes this can get more complicated because now in order to test this method, it's assumed that you can access an authenticated user. So here's another example where you could say, well, give me an ID if you want, and this will extend our API. And it also makes the test that much easier to write.

So here's another example where you could say, well, give me an ID if you want, and this will extend our API. And it also makes the test that much easier to write. Because now when I'm testing, I can say get Stripe customer ID, mock ID. And now I no longer have to assume an authenticated user. So now we could say exact same thing. If you gave us an ID, we're going to use that. Otherwise, only on that condition will we make this query. Once again, we're favoring full testability and a more intelligent and intuitive API. You could even do things like in your layer of whole projects, like if you want to share a user variable with all of your views, you could do something like this or give me the authenticated user. But what if that returns null? Well, maybe you want to say no matter what, I want some kind of user object that can respond to all of the methods that User does. So you could

authenticated user. But what if that returns null? Well, maybe you want to say no matter what, I want some kind of user object that can respond to all of the methods that user does. So you could always do something like you could create a null user for your project. So now if the user is signed in, then their user object will be made available. Otherwise, if they're not signed in, we're going to have a null user that still conforms and responds to all of the same messages, but it will just default to null for each of those methods. Useful. Same thing. Maybe you have another class that will filter request params from the query string, and you'll have something like in your constructor, you'll accept those params, right? But once again, maybe you want to say, well, you can give me params if you want, especially for the test, so that I can easily test this. But it would be nice if I could just default to what's in the request. So params

well, you can give me params if you want, especially for the test, so that I can easily test this. But it would be nice if I could just default to what's in the request. So params or default to what's in the request. Works great. Okay, one final one. How about once again, you have a method like getFeaturedSeries, something like Series, where you want to fetch all featured series IDs, and that will be returned in a collection. Well, once again, it would be nice if we could control this. So maybe we could give the IDs that we want to fetch, like so. Or we want to default to maybe what we have stored in a service provider or in a configuration file. So once again, I could say IDs equals whatever you gave me. We'll use those if you want. Otherwise, we're going to look in our Series config file and get featured series, something like that. And then you would say series findsMany IDs. So once again, and to close out

if you want. Otherwise, we're going to look in our Laravel config file and get featured series, something like that. And then you would say Series findsMany IDs. So once again, and to close out the video, we are using the ternary operator to make our API that much more intelligent and intuitive, while still allowing it to be 100% testable. It's the best of both worlds.