In my music streaming life I've gone through: Rdio, Deezer, Tidal, Apple Music, Google Music, YouTube Music, and Spotify. Of all of these, two stood out for letting me upload my own music and listen to it online: Apple Music and Google Music. This was important in the early days of the transition from mp3 to streaming because I had a massive music library and didn't want to lose it. Over time this became less relevant.

Chaos vs calm

The reality is that I started using Spotify many years ago, I started with "Oi Rdio" and then migrated to Spotify when it officially arrived here in Brazil. I liked it, the interface was simple, easy to understand and use. It was possible to know where everything was.

Notice how simple it was: a simple music list, a mini player on the right, a "Your Music" tab where you naturally accessed your library, the Radio, discovery, and search tabs.

That was it. Everything was so easy.

Today Spotify borders on chaos. To be fair, I'll use an album screen, which is the "cleanest" one in the entire service.

Now answer me: Why?

Yes, maybe it got prettier if we look at aesthetics, but we have way more information that's not always relevant and a screen where it's hard to understand which path to follow. It's worth noting that the bottom mini player is perhaps a big hit.

Search moved to the top, as did the home icon. So supposedly the main navigation is there? No! It happens in the left bar where there's that almost indistinguishable sequence of stuff. Yes, stuff, because there's everything there: artists, albums, folders, playlists, podcasts... It's a miracle there's no Instagram-style stories in there.

And Spotify expanded its domains, decided it was going to offer podcasts, which until then was one of the few remaining media that hadn't been appropriated by any monopolistic platform. Well then, someone thought that just because both were audio it made sense to shove them all into the same interface. Now my chaotic "home" that looks like TimesSquare has podcasts too, look how easy to understand...

Anyway, chaos. I love having information, but sometimes I just wanted to listen to a song without being bombarded by every color in existence. I don't want to have on Spotify the same choice dilemma I have on Netflix. I want it to be easy and fast to choose and listen to a song.

And mind you, any other platform is not as bad. Not all are like Deezer, but at least the navigation makes sense.

Belonging

Another thing I looked for in other streaming services that Spotify didn't deliver and I recently discovered: belonging. After years of being bombarded by algorithm suggestions, ads, and even podcasts I realized I wanted to listen to my music. Not my old songs, it wasn't the feeling of nostalgia, but I wanted to have the sense that I had a music library that I chose and wanted to have easy access to those songs.

If for some reason I stumbled upon a song I liked, I add it to my library and it stays there forever. When I stop one day between meetings and just want to listen to a song, without knowing what I want, I'd play the library and maybe it would come up again.

They were my songs, the songs that for whatever reason I decided to carry with me to all places, moments, and times.

Guess what? Spotify killed the old "My Music". It doesn't exist anymore. There's nowhere in the entire platform where I can listen to all the songs I've saved. Tidal has it. Apple Music has it. Deezer has it. But Spotify decided that people can now only listen to playlists. "Oh, but there's the "Liked Songs" playlist".... So, you mean their solution was a playlist called "Liked Songs" when the platform doesn't even have a like button? Because excuse me, but a "+" isn't liking. And the best part... Open an album and "like" it by clicking the "+" button. Know what happens? The "+" button when inside the album doesn't add anything to the liked songs playlist, it adds to your library, which basically means it starts showing up in the side bar full of stuff. Yes, the same button, same design, in one place serves to like the song and in the other to add the album to the library, and these are two completely distinct actions.

So that's it. I know this doesn't bother everyone, but I think it's senseless. I wonder what kind of metrics were used in those A/B tests. I listen to music in a specific way, I almost never know what I want to hear. I put on a selection of songs I like (my library) and wait for one to come up that matches my mood. And now I can't do that anymore, at least not on Spotify.

Toxic Relationship

With so many music streams and with such clear hatred, why do I still find myself returning to Spotify sometimes?

Its recommendation algorithm is good. And it's the only one that manages to mix Brazilian music well with others. I recently returned to it, I spent ~1 year on Apple Music and was having a really hard time discovering new artists and songs because at a certain point Apple Music was just sending me more of the same, more of what I already listened to.

I'll give Deezer and Tidal another chance. I dunno. I'll come back here later to tell you about it.

But what are APIs, really?

In this short series I'll try to bring some basic concepts I've learned throughout my career and through my hobbies to help new PMs or just to have it on record for future reference. Today we're talking about APIs, focusing on REST.

Architecture and APIs.

Pretty much every digital product works with three main building blocks: the client/interface, a server, and a database.

• The client/interface is where the user normally interacts: a website, a mobile app, a .exe on the computer, etc.
• The server is a computer connected to the internet that will process whatever you ask of it. (one day I'll write one of these posts about servers/internet)
• The database is where any information you want to store is kept. Think of it as a beautiful .csv or an Excel spreadsheet: columns and values.

When you search for something on MercadoLivre, the site rendered on your computer sends a request to the server. This request/communication is made via an application programming interface, an API.

How does an API work?

APIs are everywhere on the internet. There are 3 types of them:

• Public: APIs that can be used and accessed by anyone. It means any developer can use them and build stuff with them.
• Private: Used internally within companies; say a company has an application that communicates with another internal application with sensitive data, a private API makes this communication happen securely and isn't accessible to outsiders.
• Partner: A middle ground between the two above, usually these are company APIs that allow solutions to be built but require a partnership level. Twitter, for example, had an API that allowed other apps to send and read tweets and developers were required to be partners and make payments proportional to API usage. Unfortunately, Twitter killed that a few months ago.

Now, how does an API actually work?

Breaking it down into steps, it goes more or less like this:

1. When you go to MercadoLivre and type "iPhone" in the search, the site sends a request to the API, let's say api.mercadolivre.com, asking for all products named iPhone.
2. The server processes the request and runs a "query" on the database.
3. The database returns to the server a listing of all products that are iPhone 15.
4. The server grabs that listing and sends it to the site/client.

And then you'll finally see a list of iPhones on your screen.

The server isn't the API or vice versa. The API is an application running on the server. It's a set of actions available to the client. In this case, the listing action is one of the features of the API running on the server.

These actions are what we call endpoints. Imagine that besides needing to list products, the MercadoLivre API also needs to inform the shipping cost, the seller's reputation, etc. Each of these actions is an endpoint.

Examples:

• Let's say you listed the iPhones using the listing endpoint.
  • A request for iPhone is sent to api.mercadolivre.com/listing, which will return the product listing for that term.
• Now you want to calculate shipping.
  • A request is sent with your ZIP code to api.mercadolivre.com/frete, which returns the R$45 shipping cost.

You get the idea. So we're saying the API lives at api.mercadolivre.com and the endpoint is /listing.

POST and GET

There are several types of requests that can be made to an API; the two main and most common ones are POST and GET.

GET requests are more simplified and less secure requests, because as you'll see below the entire request is visible in the URL. In the previous example, if you go to MercadoLivre and want the iPhone listing. It's a GET request to the /linsting endpoint on the API that will deliver the listing to you. GET requests send information in the URL as parameters.

https://api.mercadolivre.com/listing?product=iphone

POST requests are requests that submit data to the server in the request body and not in the URL. So, when you send a POST to an endpoint you send what we call a body, which can be a set of parameters and values. POST is commonly used in requests that require more information because GET has a limit of 2,048 characters. Below is an example of a POST with a cart built on MercadoLivre.

https://api.mercadolivre.com/cart

Body:

Types of APIs

There are different types of API specifications. I won't go into detail because it's a deeper level, but these three are worth highlighting:

• REST: The most common one, it uses the http/web protocol to receive requests. It's the one that uses the GET and POST requests above and what we focused on in this text.
• SOAP: An older specification that uses only XML as its format.
• GraphQL: A very recent specification created at Facebook/META, it focuses on efficiency by bringing only the requested data and nothing else, besides allowing data to be extracted from multiple sources using just one request. It can also have mutations to work like a POST creating resources.

If you want to dive deeper into any of these topics, I've left some links at the end of the post that I used in the past to study them.

Conclusion

APIs are applications that run on servers and execute actions through endpoints; they can be public or private. APIs are everywhere on the internet and in products. They're part of any Product Manager's reality, and it's important to have basic knowledge of them because it will make communication with developers a lot easier and maybe even help find possible solutions to certain problems.

disclaimer: This text is a simplification meant to present initial technology concepts to a non-technical audience, such as Product Managers or the curious. The author is not a developer, and the information provided is generalized to facilitate initial understanding. It is recommended to consult additional sources for a more complete and accurate understanding.

Useful links:

What is an API? – Explanation about application programming interfaces – AWS

Find out what an API is, how and why companies use APIs, and how to use APIs on AWS.

Amazon Web Services, Inc.

What is an API: what it's for and how to use it

What an API is and what it's for. How APIs work. What types of APIs exist. How to create and use an API. API examples.

EbacEBAC Team

What is an API? API guide for beginners

APIs are sets of tools, definitions, and protocols for developing and integrating software applications. API stands for application programming interface.

Red Hat Summit

HTTP: GET and POST - Learn the differences between the methods | Alura

See the differences between HTTP's GET and POST methods. See the functionality of each one and when to use them on the web.

AluraAlura