Discussion :

[gavelin]

Hello

Je développe une API REST sur mon site
Je voudrais que quand une erreur survient, ma méthode ne renvoie rien, seulement un code HTTP d'erreur personnalisé (par ex HTTP 601..)

Je n'ai aucune idée de comment faire cela dans mon action
Voila l'action en question :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
 
class rewardActions extends sfActions
{
  public function executeList(sfWebRequest $request) {
    $this->rewards = array();
    $i=0;
 
    $rewards = Doctrine_Core::getTable('Reward')->findAll();
 
 
    foreach ($rewards as $reward) { 
      $this->rewards[$i++] = $reward->asArray($request->getHost().$request->getScriptName());      
    }
    $this->getResponse()->setHttpHeader('Content-type', 'application/json');
    $this->getResponse()->setContent(json_encode($this->rewards));
    return sfView::NONE;
  } 
}

Dans ce cas, je veux que si $reward->asArray() envoie une exception, le code HTTP renvoyé soit 601 et non "200" comme actuellement (car réponse à la requete "GET")
Comment faire pour cela ??

Merci d'avance!

[Michel Rotta]

Il n'y a pas un setStatusCode() ou un setCodeStatus() dans les méthodes de l'objet sfWebResponse ?

[gavelin]

et bien l'objet "response" est de type sfResponse et pas sfWebResponse non ?
sur l'objet sfResponse je n'ai pas de "setStatusCode".

[Michel Rotta]

La méthode fait partie de sfWebReponse.

Mais je ne sais pas très bien où se situe la limite entre les deux.

Je pense n'avoir jamais utilisé que le sfWebRéponse...

REST est un protocole qui utilise le HTTP pour le transport, donc il me semblerait logique de baser la réponse sur le sfWebReponse, non ?

[gavelin]

Oui effectivement :
La fonction a utiliser est :
$this->getResponse()->setStatusCode(XXX,'custom message');

il faut bien faire attention au sfWebResponse, c'est le premier point :

- Dans le "factories.yml"

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
dev:
  mailer:
    param:
      delivery_strategy: none
 
  response:
    class: sfWebResponse
    param:
      send_http_headers: true

-Et aussi, DESACTIVER LA DEBUG BAR dans le "settings.yml" de l'application !! (car sans ça, vous allez toujours avoir des codes 200, même avec le setStatusCode() ).

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

web_debug:              false

[Michel Rotta]

Ton service n'est pas sensé appeler l'application en mode debug. Et en mode normal, la debug barre devrait être désactivée...

[gavelin]

Effectivement, sauf que sur mon appli, je suis en contexte "dev" et donc avec la barre par défaut ! donc en testant l'API sur le contexte "dev" avec la barre donc, cela ne fonctionnait pas

[Michel Rotta]

En contexte "dev" dans l'appli ?

Bon, chacun fait comme il veut, mais je ne pense pas que cela soit courrant.

[gavelin]

looool en général vaut mieux commencer par le contexte "dev" avant de passer en contexte "test" et ensuite en "prod" non ?

[Michel Rotta]

Je pense que l'on parle de choses différentes.

Je parle de lancer l'application avec le contrôleur de dev : frontend_dev.php.

De ce que j'ai compris, tu préfères basculer le mode dev sur toute l'application.

L'avantage avec le mode dev dans le contrôleur c'est que si tu fais un appel REST sur l'url 'standart' de l'application, elle n'est pas en dev, ce qui est plus simple (a mon avis) pour tester un REST. Tu peux toujours lancer la demande depuis un explorateur en mode dev à l'aide du contrôleur, l'explorateur peut afficher le contenu généré.