Buena pregunta. Dependiendo del caso de uso de su aplicación, puede haber varias formas de hacerlo. Aquí hay algunas pautas generales:
Use un esquema personalizado en lugar de un esquema http
Por ejemplo, considere usar un esquema URI personalizado como catalogspree: // vs. un esquema http como http://m.catalogspree.com/my_uri. Las razones son dobles.
- ¿Son iguales los casos de prueba para un sitio web y una aplicación móvil o son diferentes?
- ¿Cuánto gana un desarrollador novato de Android con sus pequeñas aplicaciones?
- ¿Cuál se recomienda para una plataforma Q2A?
- ¿Por qué la mayoría de las aplicaciones móviles multiplataforma usan iCloud y Google Cloud para la sincronización en lugar de usar un servidor al que se puede acceder desde cualquier sistema operativo móvil? ¿Son más baratos (quizás gratis) o más seguros?
- ¿Lanzarías primero una aplicación de noticias sobre dispositivos tecnológicos para iOS o Android?
El primero es que los esquemas HTTP son ambiguos. Cuando un navegador se enfrenta a un esquema HTTP, tiene que hacer la pregunta: “¿Abro un sitio web o inicio una aplicación?”. Chrome resuelve este problema al proporcionar un cuadro de diálogo para que un usuario elija, mientras que otros navegadores personalizados ni siquiera consideran iniciar la aplicación. Un esquema personalizado anula esta ambigüedad.
En segundo lugar, un esquema personalizado le permite definir un enlace más conciso en su aplicación. Con un esquema HTTP, como mínimo, debe definir un “dominio” único después de http como “http: //my_unique_domain.xx”. Con un esquema personalizado, simplemente puede definir “my_custom_scheme: //”, que además de la brevedad, también puede ayudar con la marca de su aplicación.
Usa la barra doble: //
Un pequeño punto técnico, pero al implementarlo, maneje algo como catalogspree: // con la barra doble en lugar de catalogspree: con dos puntos. Esto le permitirá aprovechar las bibliotecas de análisis de URI de manera más efectiva ya que un solo colon no se maneja bien con muchos analizadores de URI.
Piensa en el enlace profundo
En estos días se está volviendo más común ver a una empresa brindar su servicio a través de la web y también a través de una aplicación. Un ejemplo es Amazon donde venden productos a través de amazon.com y su propia aplicación para iPhone. Para impulsar los negocios a través del iPhone, definen esquemas de URI que le permiten conectarse directamente a los productos dentro de la aplicación, lo que a su vez les facilita la promoción de productos directamente. Entonces, una pregunta es si su esquema URI expone las funciones más importantes dentro de su aplicación.
Estar tranquilo
Si su intención es que su esquema URI se enganche en múltiples lugares dentro de su aplicación, la coherencia en la estructura es primordial. Los patrones de estilo RESTful del mundo web tienden a funcionar bien en esta área.
Un ejemplo de un esquema RESTful URI para ver / ordenar un determinado producto o categoría sería:
custom_shopping_app: // productos / 123
custom_shopping_app: // productos / 123 / orden
custom_shopping_app: // categories / abc
Un ejemplo no RESTful sería:
custom_shopping_app: // view? product_id = 123
custom_shopping_app: // view? category_id = abc
En el ejemplo RESTful, puede ver que los URI se definen en función de los “recursos” de la aplicación, es decir, productos y categorías.
Varias ventajas siguen:
Primero, el esquema explica más claramente lo que realmente quiere hacer y lo que desea operar, es decir, ¿quiero ver una categoría o un producto? El ejemplo no RESTful confunde los dos conceptos juntos.
El segundo es técnico. Dentro de una aplicación, si elige el esquema no RESTful, tendría que definir un punto de entrada para “ver” y luego analizar los parámetros para indicar si se debe mostrar un producto o categoría. El esquema RESTful, por otro lado, separa las preocupaciones al permitirle aislar los puntos de entrada para productos y categorías.
En tercer lugar, las URL de estilo RESTful están ganando una amplia adopción en todo el mundo web. Al definir un esquema URI que siga patrones similares, la integración será mucho más fácil.
En resumen, piense en definir cada uno de sus URI como una “acción” singular que opera en un tipo específico de “recurso”.
Esta es probablemente una gran simplificación de lo que realmente significa ser RESTful, pero aquí hay una buena descripción de cómo RESTful se aplica a las URL:
http://stackoverflow.com/questio…
Se consistente
Sé que esto suena obvio, pero es sorprendente ver cuántas aplicaciones usan un esquema diferente para su aplicación de iPhone frente a su aplicación de Android. Más aún, si su aplicación es un reflejo de su producto web, será útil lograr consistencia y similitud entre la estructura de URL y URI.
Por ejemplo, si tiene un sitio de compras con una URL a un producto como tal:
http://www.myshoppingsite.com/products/123
Idealmente, querrá que su URI también sea:
myshoppingsite: // productos / 123
Documento.
Por último, pero no menos importante, documento documento documento 🙂
Divulgación completa: trabajo en SPARQ que se especializa en tecnología de enlaces profundos. Puede leer más sobre los matices técnicos de los URI aquí: https://www.sparq.it/web/api/v1/docs/mobile_uris
