API REST Salesforce avec package géré

Question

Nous avons implémenté un service de repos dans un package géré. Quelques uns de nos clients ont déjà installé ce paquet. Actuellement, il faut 3 paramètres. L'objectif est d'envoyer les mises à jour effectuées dans un système à une instance Salesforce avec le package géré installé. Dans la construction de ce service, nous avons suivi les exemples décrits ici ... ..

https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_rest_methods.htm

Nous voulons ajouter un paramètre optionnel à notre appel de méthode POST. Passez de 3 paramètres à 4 par exemple. Nous voulons que ce changement soit rétrocompatible. Ce que nous voyons en essayant de tester cela est une erreur "Resource Not Found" lors de l'envoi de 4 paramètres plutôt que les 3 anciens paramètres.

Est-il possible de mettre à jour le code du service de repos sans que tous nos clients l'installent à nouveau? Ou Est-ce que quelqu'un qui a installé le paquet géré doit sortir et obtenir un nouveau paquet pour lire le nouveau paramètre? Quelle est la meilleure façon de gérer les modifications ou les mises à jour comme celle-ci?

Y a-t-il une meilleure implémentation ou façon de gérer ce type de scénario? Est-ce la responsabilité de l'utilisateur de déterminer la version API/package installée et de passer trois ou quatre paramètres?

Si vous pouvez partager les meilleures pratiques concernant la mise à niveau de la mise en œuvre de la méthode de l'API REST dans Salesforce, il est vraiment apprécié.

Exemple Old Way: ../apex/updateSomething envoyé avec JSON dans le corps { "Element1": "Valeur1", "Element2": "Valeur2", "Element3": "Value3"}

Exemple Nouvelle façon: ../apex/updateQuelque chose envoyée avec json dans le corps {"Element1": "Value1", "Element2": "Value2", "Element3": "Value3", "Element4": "Value4"}

Answer 1

Je vois deux questions différentes, je vais essayer d'aborder les deux.

1. "Doivent-ils sortir et se mettre à niveau?". Non, ils ne le font pas, vous pouvez pousser la mise à niveau: https://developer.salesforce.com/docs/atlas.en-us.packagingGuide.meta/packagingGuide/push_upgrade_intro.htm
2. "Comment pouvons-nous rendre cela rétrocompatible?". Ne pouvez-vous pas conserver l'ancienne méthode pour trois paramètres d'entrée et en créer une nouvelle pour quatre?

Il est plus difficile de donner une réponse sans code spécifique.

Answer 2

Il y a différentes manières d'accomplir ceci.

La première est la gestion des versions. En ajoutant le v1, les utilisateurs finaux peuvent utiliser les différentes versions et mettre à niveau vers des versions plus récentes quand elles sont prêtes. La prochaine version peut être
@RestResource(urlMapping = '/DemoEndpoint/v2/*')

Versioning est recommandé pour les points d'extrémité de l'API. Vous devrez créer des classes séparées pour chaque version.

La deuxième méthode consiste à modifier la façon dont vous acceptez les paramètres d'entrée. Dans ce scénario, supprimez les paramètres d'entrée dans la définition de la méthode et utilisez Request.requestbody.

Voici le code d'origine (en supposant que vous avez suivi l'exemple de guide du développeur)
@HttpPost global static void myPostMethod(string Element1, string Element2, string Element3, string Element4)

code Nouvelle acceptation 3 ou 4 paramètres (ou 0 paramètres, voir note ci-dessous).

@HttpPost 
global static string myPostMethod() { 
    RestRequest request = RestContext.request; 
    String body = request.requestBody.toString(); 
    List<Wrapper> obj = (List<Wrapper>) JSON.deserialize(body, List<Wrapper>.Class); 

La classe wrapper serait

public class Wrapper{ 
    string Element1; 
    string Element2; 
    string Element3; 
    string Element4; 
} 

Si Element4 est vide, il n'a pas été adoptée. À l'aide de cette méthode, vous devez faire la validation des entrées. Par exemple, cela acceptera un zéro et tous les éléments seront vides.