{"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\/pt\/mobile-developers-is-rest-keeping-you-up-at-night\/","title":{"rendered":"Desenvolvedores m\u00f3veis: O REST est\u00e1 tirando seu sono?"},"content":{"rendered":"

RE<\/b>de apresenta\u00e7\u00e3o <\/span>S<\/b>estado <\/span>T<\/b>ransfer\u00eancia, comumente conhecida como \"REST\", descreve um padr\u00e3o para comunica\u00e7\u00e3o program\u00e1tica com servi\u00e7os de dados de back-end pela Web.<\/span><\/p>\n

Uma API REST \u00e9 uma interface de programa\u00e7\u00e3o que usa solicita\u00e7\u00f5es HTTP para POST (criar), GET (ler), PUT (atualizar) e DELETE dados (conhecidos como \"opera\u00e7\u00f5es CRUD\") por meio de um endpoint de URL b\u00e1sico semelhante a <\/span>https:\/\/sample.com\/api\/products<\/span><\/i>. Os desenvolvedores criam aplicativos que interagem com a API por meio de solicita\u00e7\u00f5es HTTP para o ponto de extremidade.<\/span><\/p>\n

Pense nos pontos de extremidade da API REST como encapsulamentos de consultas que s\u00e3o expostas para que os desenvolvedores interajam com uma fonte de dados. A abstra\u00e7\u00e3o da complexidade facilita o uso da REST - \u00e9 apenas um URL, mas lembre-se de que somente as consultas que os autores da API pensaram e expuseram est\u00e3o dispon\u00edveis para as massas; a manipula\u00e7\u00e3o de dados al\u00e9m dessas consultas requer programa\u00e7\u00e3o.<\/span><\/p>\n

Devido \u00e0 sua simplicidade e ao fato de que quase todas as principais solu\u00e7\u00f5es de software oferecem acesso REST, o aproveitamento das APIs REST para dados tornou-se uma abordagem popular para o desenvolvimento de aplicativos Web.<\/span><\/p>\n

Por que REST em primeiro lugar?<\/span><\/h2>\n

As APIs REST s\u00e3o uma \u00f3tima op\u00e7\u00e3o para muitos aplicativos, especialmente os menos complexos, com requisitos b\u00e1sicos para buscar e atualizar registros.<\/span><\/p>\n

Por exemplo, um aplicativo que mostra \"locais pr\u00f3ximos a mim\" para um varejista pode passar as coordenadas de localiza\u00e7\u00e3o do usu\u00e1rio para um endpoint REST, como <\/span>\"<\/span>https:\/\/sample.com\/api\/locations\/?=___<\/span><\/i>\", que retorna endere\u00e7os de lojas em um determinado raio daquele local. Todas as informa\u00e7\u00f5es que o aplicativo precisa para o recurso \"locais pr\u00f3ximos a mim\" s\u00e3o fornecidas por meio de um simples <\/span>OBTER<\/span><\/em> chamada. Por esses tipos de motivos, o REST \u00e9 bom quando as necessidades de dados do aplicativo podem ser atendidas com acesso geral \u00e0s entidades.<\/span><\/p>\n

Mas se o seu aplicativo exigir mais l\u00f3gica para o manuseio de dados, como aqueles que modificam frequentemente entidades como usu\u00e1rios, contas ou invent\u00e1rios, voc\u00ea provavelmente precisar\u00e1 de um controle mais granular dos dados do que muitas APIs REST podem oferecer. Isso for\u00e7a os desenvolvedores a situa\u00e7\u00f5es em que precisam codificar em torno das limita\u00e7\u00f5es do REST para obter os dados precisos que o aplicativo exige, fazendo coisas como filtrar e mesclar dados no c\u00f3digo, o que leva mais tempo e inevitavelmente reduz a efici\u00eancia do aplicativo.<\/span><\/p>\n

Al\u00e9m disso, como o aplicativo \u00e9 m\u00f3vel, voc\u00ea tamb\u00e9m precisa lidar com problemas de conectividade ao depender de APIs REST na Web para obter dados, o que n\u00e3o \u00e9 uma tarefa trivial.<\/span><\/p>\n

\u00c9 aqui que voc\u00ea provavelmente come\u00e7ar\u00e1 a enfrentar os pontos problem\u00e1ticos da API REST...<\/span><\/p>\n

Pontos problem\u00e1ticos do uso do REST<\/span><\/h2>\n

Falta de valida\u00e7\u00e3o do esquema e do tipo de dados<\/span><\/h3>\n

Cada API REST \u00e9 criada especificamente para as entidades que exp\u00f5e e, portanto, n\u00e3o h\u00e1 um protocolo padr\u00e3o para valida\u00e7\u00e3o de esquema ou tipos de dados esperados. Isso significa que os desenvolvedores devem estar cientes desses detalhes e contorn\u00e1-los, ou sofrer as consequ\u00eancias em termos de instabilidade e falhas no aplicativo.<\/span><\/p>\n

Por exemplo, voc\u00ea pode enviar uma solicita\u00e7\u00e3o de uma lista de produtos usando \"<\/span>GET \/produtos<\/span><\/em>\", mas n\u00e3o h\u00e1 como validar se o endpoint existe. Isso \u00e9 especialmente problem\u00e1tico quando voc\u00ea usa um endpoint que estava dispon\u00edvel em vers\u00f5es anteriores de uma API que n\u00e3o est\u00e1 mais dispon\u00edvel em vers\u00f5es mais recentes.<\/span><\/p>\n

E mesmo que o endpoint exista, n\u00e3o h\u00e1 como validar os detalhes da entidade que ele retorna. Por exemplo, um determinado produto na lista de produtos retornada pode ter sido modificado ou exclu\u00eddo por outro cliente desde que a lista foi solicitada.<\/span><\/p>\n

Os tipos de dados tamb\u00e9m podem ser diferentes para os mesmos dados entre os endpoints, dependendo de como cada um foi implementado. Por exemplo, essas duas solicita\u00e7\u00f5es de endpoint retornar\u00e3o os mesmos dados, mas com pequenas diferen\u00e7as:<\/span><\/p>\n\n\n\n\n\n
Solicita\u00e7\u00e3o<\/b><\/td>\nResposta<\/b><\/td>\n<\/tr>\n
GET \/produtos\/123<\/span><\/td>\n{
\n<\/span>\u00a0Pre\u00e7o: 10,95,
\n<\/span>\u00a0Moeda: \"USD\"
\n<\/span>}<\/span><\/td>\n<\/tr>\n
GET \/inventory\/product\/123<\/span><\/td>\n{
\n<\/span>\u00a0Pre\u00e7o: \"10.95\",
\n<\/span>\u00a0Moeda: \"USD\"
\n<\/span>}<\/span><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

Neste exemplo, uma resposta retorna o pre\u00e7o do produto como double e a outra retorna o pre\u00e7o do produto como uma string. Esses s\u00e3o os tipos de incompatibilidade de tipos de dados que podem causar instabilidade ou falha nos aplicativos.<\/span><\/p>\n

Transforma\u00e7\u00e3o de dados de ida e volta<\/span><\/h3>\n

A manipula\u00e7\u00e3o de tipos de dados requer um ciclo intermin\u00e1vel de transforma\u00e7\u00e3o dos dados da entidade no que cada extremidade da conex\u00e3o espera. Por exemplo, para que um aplicativo aproveite uma API REST, o fluxo de comunica\u00e7\u00e3o seria mais ou menos assim:<\/span><\/p>\n\n\n\n\n\n\n\n
\n
    \n
  1. Definir modelos de dados de entidade<\/span><\/li>\n<\/ol>\n<\/td>\n
\n
    \n
  • Definir modelos de dados em c\u00f3digo nativo<\/span><\/li>\n<\/ul>\n<\/td>\n<\/tr>\n
2. Serializar dados em JSON<\/span><\/td>\n\n
    \n
  • Converta objetos nativos em JSON<\/span><\/li>\n
  • Formatar entidades de dados nativos em uma estrutura que seu ponto de extremidade REST espera<\/span><\/li>\n<\/ul>\n<\/td>\n<\/tr>\n
3. Transporte via HTTP<\/span><\/td>\n\n
    \n
  • Codificar dados como uma cadeia de caracteres JSON<\/span><\/li>\n
  • Codificar a cadeia de caracteres JSON como dados de formul\u00e1rio HTTP de v\u00e1rias partes<\/span><\/li>\n
  • Enviar uma solicita\u00e7\u00e3o POST<\/span><\/li>\n<\/ul>\n<\/td>\n<\/tr>\n
4. Decodificar dados no backend<\/span><\/td>\n\n
    \n
  • Decodificar dados do POST<\/span><\/li>\n
  • Decodificar a cadeia de caracteres JSON<\/span><\/li>\n<\/ul>\n<\/td>\n<\/tr>\n
5. Opera\u00e7\u00e3o CRUD no banco de dados<\/span><\/td>\n\n