Bom pessoal, no vídeo anterior a gente falou sobre entidades relacionadas, entidades core, e agora eu quero falar para você sobre o design de API. Isso aqui você tem que tomar muito cuidado, porque muitos desenvolvedores acabam pirando nessa parada, e normalmente, por exemplo, numa entrevista, você vai gastar um tempo gigantesco para fazer o design de uma API. O design da API no System Design, na realidade, ele vai focar principalmente nos recursos baseados nos requisitos funcionais. Então, quando eu vou falar que eu quero criar o design de uma API, eu vou fazer isso da forma mais simples possível. Por exemplo, o passageiro e o cliente solicitam uma nova corrida a partir de uma localização e um destino. Como que eu posso fazer isso? Eu posso colocar que eu vou ter um post, onde eu vou ter por exemplo, passageiro, né, ou rider, né, normalmente chama rider, ok? Barra rider, onde ele vai solicitar uma nova uma nova corrida, tá? Um rider barra request alguma coisa, tá? Então eu vou dar um exemplo aqui pra gente. Então esse cara aqui é um request rider barra request, né? Ou request ride. O nome que a gente quiser aqui. Legal? Uma vez que eu tenho essa informação, o que eu boto aqui na hora de eu fazer o design da minha API? Aqui de cara, o que você pode fazer é passar de cara quem são os caras que vão trabalhar aqui nesse ponto. Então, o que eu vou precisar aqui no final das contas é, eu vou passar o rider ID, né? Quem é o cara. Eu vou passar a location, né? Aonde ele está. Então, eu posso passar a location onde que está o rider. Legal? E eu vou passar a destination aonde esse cara vai tá, aqui pra mim, beleza? Então, isso aqui é um exemplo muito simples de design de API, qualquer pessoa que acaba olhando, acaba trabalhando aqui. Uma outra coisa que você pode fazer, dependendo da situação, você pode, às vezes, até esconder o Rider ID, porque pode estar implícito aqui que você tem algum token que identifica o Rider. A ideia que eu estou querendo trazer aqui para você, dependendo da situação, é que você vai passar isso aqui da forma mais simples possível, apenas pra que quem bate o olho entenda o que que esse endpoint, ele acaba fazendo, tá? Esse é a grande questão. Você não precisa ficar colocando centeiro, você não precisa escrever isso em JSON, entendeu? Coloca aqui, tá claro, pra todo mundo que olha o que que tá acontecendo aí, tá? Então, esse aí é um ponto super importante aí nesse nosso caso aí pra gente, tá? Então, fica ligado com esse tipo de design de API. Agora, a dica que eu dou também é, na hora que você for fazer o design da API, você vai ver o requisito funcional, tá? E baseado nesse requisito, você cria os endpoints referentes a ele, né? Aqui nesse caso, o passageiro solicita uma nova corrida a partir de uma localização. Pum! Isso aqui, eu matei, né? Esse requisito funcional. Eu sei que eu já estou cumprindo o que ali está acontecendo. O ponto é que a gente vai ter diversos recursos, como se diz, diversos recursos aqui para a gente. E aí, nesse caso, a gente vai criando um endpoint para cada cara. Então, é importantíssimo aqui que você consiga trabalhar. Bacana? Então, fica ligado porque vale a pena a gente conseguir se ligar. Uma outra coisa que você pode fazer também é sempre entender por onde o design da sua API começa, né? E por qual a entidade. Por exemplo, aqui, ó. Eu posso colocar aqui um rider. Ele faz um request, uma ride, né? Ou eu posso colocar que eu tenho uma ride, que é uma corrida, e eu tenho uma nova request de uma nova corrida, tá? Então, eu tenho uma ride, uma corrida aqui, né? E aqui, eu tenho uma request, uma nova corrida, onde eu tenho a localização, né? Start. corrida, onde eu tenho a localização, né? A start, a start e a destination, né? Onde que ele tá, onde ele tá, o location atual, né? E se eu quiser eu posso deixar isso mais expressivo, por exemplo, rider, location, qualquer coisa desse tipo que a pessoa bata o olho e consiga entender o que isso acaba fazendo. Fechou? Então, sempre quando você for fazer design de API, num requisito aqui de system design, você não vai passar disso aqui. Qualquer coisa além disso, você vai estar pirando, porque o system design, design de API, essas coisas são high level, galera. Não vai querer botar um design design de API, essas coisas são high level galera não vai querer botar um padrão open API e aí qualquer coisa desse tipo, normalmente inclusive se você tiver entrevista, são 40, 50 minutos de entrevista, o quanto menos você escrever e o mais você conseguir se expressar aí é melhor, fechou? então é dessa forma que a gente vai trabalhar com design de API