Using a RESTful API to get data from a music database
Catching up on REST
Craft the perfect URL to access metadata in an online music database.
Many network-based web services offer APIs that comply with the REpresentational State Transfer (REST) design style. APIs that comply with REST constraints are called RESTful.
RESTful APIs are attractive because they leverage existing HTTP infrastructure, the same infrastructure and protocols that browsers use. As a result, a RESTful API has access to a great variety of resources (applications, libraries, developers, etc.). From an end-user perspective, you can use your existing browser as a client to access server databases. Developers like RESTful APIs because it is easy to integrate server data and resources into applications.
Music services often use RESTful APIs to provide metadata about artists and musical tracks. Offering this data through a REST interface makes it very easy to build a client application that will receive and display the information. This article shows how to query music data through a RESTful API.
Why REST
A RESTful API allows the client to retrieve data from the server without needing to know details about the server back-end implementation. There is no need for the client to know which server or database management software is used. In addition, the API enhances security by restricting who can access data and selectively restricting which data is accessible.
RESTful APIs operate in two modes, request and response. The client sends a request to the server for data. The server then responds with a status code, and if appropriate, the requested data.
In a RESTful web service, requests made to a resource's URI elicit a response with a payload usually formatted in HTML, XML, or JSON. The most common data transfer protocol for these requests and responses is HTTP, which provides operations (HTTP methods) such as GET
, POST
, PUT
, PATCH
, and DELETE
. See the box entitled "More on REST" for additional background on RESTful APIs.
More on REST
RESTful APIs are built around the following design principles:
- User interface – all requests for the same information look the same, regardless of where the request came from.
- Client-server decoupling – client and server are assumed to be totally independent. The only information that passes between them is through the API.
- Statelessness – each request contains all the input necessary for processing. There is no need to establish a "session." The state of the server remains constant.
- Cacheability – data should be cacheable on the client or server to improve performance.
- Layered system architecture – intermediate layers are integrated invisibly into the architecture. The client can't tell if it is connected directly to the end server or through an intermediary. Layered components adhere to REST constraints.
- Code on demand (optional) – integration with client-side components such as Java-applets or JavaScript.
An API isolates the client from the server, allowing communication through a uniform interface. This approach facilitates the development and debug process by giving you better visibility into network components. As a result, implementation of changes on either the client side or the server side can occur without either one affecting the other, as long as the interface protocol is followed [1].
The following is a list of the REST interface constraints:
- Identification of resources
- Manipulation of resources through representations
- Self-descriptive messages
- Hypermedia as the engine of the application state
The first REST constraint, "identification of resources," uses identifiers to identify target resources. In a RESTful API, these identifiers are referred to as representations. By design, a RESTful API never manipulates server resources directly. Instead, it only manipulates their representations, the identifiers. In the example in this article, you will see how these representations are used in communication between client and server.
Music APIs
Several well-known music services provide RESTful API database access to musicians and to partners who want to integrate their content or music into commercial products.
Spotify, for example, provides an API that allows hardware partners to develop applications for home audio systems, music players, headphones, and other internet-enabled devices. According to the Spotify for Developer website, "Spotify Web API endpoints return JSON metadata about music artists, albums, and tracks, directly from the Spotify Data Catalog."
SoundCloud is a music service that allows musicians to share their music with a community of artists and listeners. Musicians can use the API to upload and manage their music for listeners.
MusicBrainz views its service as an open encyclopedia for music metadata. MusicBrainz is modeled after Wikipedia in that it is community-driven [2]. The metadata content is primarily, but not exclusively, targeted at music player and tagger applications. In this article, I will use the open source MusicBrainz API to request and receive music data through HTTP. (See the "HTTP Primer" box for more on accessing resources through HTTP.)
HTTP Primer
In order to understand RESTful APIs, it is essential to understand the role that HTTP plays. The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems [3]. HTTP was designed, from its beginning in 1990, to support the client-server model (Figure 1), with requests passing in the form of messages from a client to a server. A response message and status code then passes from the server to the client.
When HTTP was first introduced, the only method used to send requests was the GET
method. HTTP has since evolved to include additional methods to allow requests to modify and delete content on the server. Among the methods currently used are: GET
, POST
, PUT
, and DELETE
(Table 1).
When a request message is sent by a user agent (the client application) to a server, the message typically contains header fields that can include metadata such as: method, target hostname, content type, content length, and other characteristics of the client, host, or message.
Upon receiving a request from a user agent, the server determines whether it can accept the request. If accepted, the server responds by sending a status code and a message back to the client. Response message content might include metadata or the requested target resource.
Table 1
HTTP Methods
|
Asks the server to send the target resource based on an identifier (representation). |
|
Asks the server to have the target resource process the enclosed content specified by an identifier. |
|
Asks the server to have the target resource create or replace the enclosed content specified by an identifier. |
|
Asks the server to have the target resource specified by an identifier to be deleted. |
MusicBrainz API
The MusicBrainz API gives the client access to a wide range of music metadata about artists and their music, including biographical information, release dates, and media formats. Requests are in the form of a URL that is comprised of multiple components, some mandatory and some optional [4].
REST constraints require the API to be stateless. This means that each request sent by the client to the server must contain all the information the server needs to respond appropriately. As a consequence, all the necessary information is contained in the URL. In the case of MusicBrainz, the syntax for the URL is as follows:
<api_root><entity><mbid><inc><format>
<api_root>
is the partial URL to the API, in this case:
https://musicbrainz.org/ws/2/
<entity>
is one or more information categories, such as artist, recording, release, etc. <mbid>
is the MusicBrainz identifier that is unique to each target resource in the database. <inc>
is an optional subquery string. <format>
is an optional format string that specifies the transfer format, which can be either JSON or XML. (XML is the default format.)
Buy this article as PDF
(incl. VAT)
Buy Linux Magazine
Subscribe to our Linux Newsletters
Find Linux and Open Source Jobs
Subscribe to our ADMIN Newsletters
Support Our Work
Linux Magazine content is made possible with support from readers like you. Please consider contributing when you’ve found an article to be beneficial.
News
-
The Gnome Foundation Struggling to Stay Afloat
The foundation behind the Gnome desktop environment is having to go through some serious belt-tightening due to continued financial problems.
-
Thousands of Linux Servers Infected with Stealth Malware Since 2021
Perfctl is capable of remaining undetected, which makes it dangerous and hard to mitigate.
-
Halcyon Creates Anti-Ransomware Protection for Linux
As more Linux systems are targeted by ransomware, Halcyon is stepping up its protection.
-
Valve and Arch Linux Announce Collaboration
Valve and Arch have come together for two projects that will have a serious impact on the Linux distribution.
-
Hacker Successfully Runs Linux on a CPU from the Early ‘70s
From the office of "Look what I can do," Dmitry Grinberg was able to get Linux running on a processor that was created in 1971.
-
OSI and LPI Form Strategic Alliance
With a goal of strengthening Linux and open source communities, this new alliance aims to nurture the growth of more highly skilled professionals.
-
Fedora 41 Beta Available with Some Interesting Additions
If you're a Fedora fan, you'll be excited to hear the beta version of the latest release is now available for testing and includes plenty of updates.
-
AlmaLinux Unveils New Hardware Certification Process
The AlmaLinux Hardware Certification Program run by the Certification Special Interest Group (SIG) aims to ensure seamless compatibility between AlmaLinux and a wide range of hardware configurations.
-
Wind River Introduces eLxr Pro Linux Solution
eLxr Pro offers an end-to-end Linux solution backed by expert commercial support.
-
Juno Tab 3 Launches with Ubuntu 24.04
Anyone looking for a full-blown Linux tablet need look no further. Juno has released the Tab 3.