{"id":14613,"date":"2023-07-12T11:10:49","date_gmt":"2023-07-12T18:10:49","guid":{"rendered":"https:\/\/www.couchbase.com\/blog\/?p=14613"},"modified":"2025-06-13T19:56:50","modified_gmt":"2025-06-14T02:56:50","slug":"mobile-developers-is-rest-keeping-you-up-at-night","status":"publish","type":"post","link":"https:\/\/www.couchbase.com\/blog\/mobile-developers-is-rest-keeping-you-up-at-night\/","title":{"rendered":"Mobile Developers: Is REST Keeping You Up At Night?"},"content":{"rendered":"

RE<\/b>presentational <\/span>S<\/b>tate <\/span>T<\/b>ransfer, commonly known as \u201cREST\u201d, describes a standard for programmatic communication with backend data services over the web.<\/span><\/p>\n

A REST API is a programming interface that uses HTTP requests to POST (create), GET (read), PUT (update), and DELETE data (known as \u201cCRUD operations\u201d) via a basic URL endpoint similar to <\/span>https:\/\/sample.com\/api\/products<\/span><\/i>. Developers build apps that interact with the API via HTTP requests to the endpoint.<\/span><\/p>\n

Think of REST API endpoints as encapsulations of queries that are exposed for developers to interact with a source of data. The abstraction of complexity makes using REST easy\u2014it’s just a URL, but keep in mind that only those queries that the API authors have thought of and exposed are available to the masses, manipulating data beyond those queries requires programming.<\/span><\/p>\n

Because of their simplicity, and the fact that nearly every major software solution offers REST access, leveraging REST APIs for data has become a popular approach to web app development.<\/span><\/p>\n

Why REST in the first place?<\/span><\/h2>\n

REST APIs are a great option for many apps, especially those that are less complex with basic requirements for fetching and updating records.<\/span><\/p>\n

For example, an app that shows \u201clocations near me\u201d for a retailer might pass user location coordinates to a REST endpoint such as <\/span>\u201c<\/span>https:\/\/sample.com\/api\/locations\/?=___<\/span><\/i>\u201d, which returns store addresses within a given radius of that location. All the information that the app needs for the \u201clocations near me\u201d feature is delivered via a simple <\/span>GET<\/span><\/em> call. For these types of reasons, REST is good when app data needs can be fulfilled with general access to entities.<\/span><\/p>\n

But if your app requires more logic for data handling, such as those that frequently modify entities such as users, accounts or inventories, you probably need more granular control of the data than many REST APIs alone can provide. This forces developers into situations where they have to code around the limitations of REST to get the precise data that the app requires, doing things like filtering and merging data in code, which takes more time and inevitably erodes app efficiency.<\/span><\/p>\n

What’s more, because the app is mobile you also need to contend with connectivity issues when relying on REST APIs over the web for data, not a trivial task.<\/span><\/p>\n

This is where you will likely begin to hit the REST API pain points\u2026<\/span><\/p>\n

Pain points of using REST<\/span><\/h2>\n

Lack of schema and data type validation<\/span><\/h3>\n

Every REST API is built specific to the entities that it exposes, and therefore there is no standard protocol for schema validation or expected data types. This means developers must be aware of these details and work around them, or suffer the consequences in app instability and crashes.<\/span><\/p>\n

For example, you could send a request for a list of products using \u201c<\/span>GET \/products<\/span><\/em>\u201d, but there is no way to validate that the endpoint exists. This is especially troublesome when you use an endpoint that was available in previous versions of an API that is no longer available in newer versions.<\/span><\/p>\n

And even if the endpoint exists, there’s no way to validate the entity details that it returns. For example, a given product in the returned list of products may have been modified or deleted by another client since the list was requested.<\/span><\/p>\n

Data types can also differ for the same data between endpoints, depending on how each was implemented. For example, both of these endpoint requests will return the same data, but with slight differences:<\/span><\/p>\n\n\n\n\n\n
Request<\/b><\/td>\nResponse<\/b><\/td>\n<\/tr>\n
GET \/products\/123<\/span><\/td>\n{
\n<\/span>\u00a0Price: 10.95,
\n<\/span>\u00a0Currency: \u201cUSD\u201d
\n<\/span>}<\/span><\/td>\n<\/tr>\n
GET \/inventory\/product\/123<\/span><\/td>\n{
\n<\/span>\u00a0Price: \u201c10.95\u201d,
\n<\/span>\u00a0Currency: \u201cUSD\u201d
\n<\/span>}<\/span><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

In this example one response returns the product price as a double, and the other returns the product price as a string. These are the sorts of data type mismatches that can cause apps to become unstable or crash.<\/span><\/p>\n

Back-and-forth data transformation<\/span><\/h3>\n

Handling data types requires an endless cycle of transforming entity data into what each end of the connection expects. For example, for an app to leverage a REST API, the communication flow would look a bit like this:<\/span><\/p>\n\n\n\n\n\n\n\n
\n
    \n
  1. Define entity data models<\/span><\/li>\n<\/ol>\n<\/td>\n
\n
    \n
  • Define data models in native code<\/span><\/li>\n<\/ul>\n<\/td>\n<\/tr>\n
2. Serialize data into JSON<\/span><\/td>\n\n
    \n
  • Convert native objects into JSON<\/span><\/li>\n
  • Format native data entities into a structure that your REST endpoint expects<\/span><\/li>\n<\/ul>\n<\/td>\n<\/tr>\n
3. Transport via HTTP<\/span><\/td>\n\n
    \n
  • Encode data as a JSON string<\/span><\/li>\n
  • Encode JSON string as multipart HTTP form data<\/span><\/li>\n
  • Send over a POST request<\/span><\/li>\n<\/ul>\n<\/td>\n<\/tr>\n
4. Decode data on backend<\/span><\/td>\n\n
    \n
  • Decode POST data<\/span><\/li>\n
  • Decode JSON string<\/span><\/li>\n<\/ul>\n<\/td>\n<\/tr>\n
5. CRUD operation on database<\/span><\/td>\n\n