{"id":266,"date":"2018-04-20T11:12:29","date_gmt":"2018-04-20T09:12:29","guid":{"rendered":"https:\/\/corsaire-consulting.fr\/blog\/?p=266"},"modified":"2018-04-20T11:17:27","modified_gmt":"2018-04-20T09:17:27","slug":"weblogic-server-12c-restful-management-api-sessions-http","status":"publish","type":"post","link":"https:\/\/corsaire-consulting.fr\/blog\/index.php\/2018\/04\/20\/weblogic-server-12c-restful-management-api-sessions-http\/","title":{"rendered":"WebLogic Server 12c – RESTFul Management API & Sessions HTTP"},"content":{"rendered":"

Depuis la version 12c, WebLogic Server expose certains de ces services au travers d’une interface RESTFUL. Vous pouvez consulter la documentation<\/a> officielle pour avoir davantage d’informations sur le sujet.<\/p>\n

Ceux connaissant d\u00e9j\u00e0 les fondamentaux des API REST ont du \u00eatre surpris par le titre de l’article mentionnant les sessions HTTP.
\nEn effet, une architecture REST stipule que le serveur est SANS ETAT. C’est \u00e0 dire que le client doit envoyer syst\u00e9matiquement toutes les informations requises au serveur afin qu’il puisse traiter sa requ\u00eate. Le serveur ne conservant aucune information sur le client une fois la requ\u00eate trait\u00e9e.<\/p>\n

<\/p>\n

Revenons \u00e0 WebLogic Server. Il expose donc pas mal de services d’administration au travers d’une API REST qui permettent de consulter ou de modifier la configuration du domaine ainsi que de consulter les m\u00e9triques des composants pendant le run.<\/p>\n

L’appel d’une simple URL telle que http:\/\/<host>:<port>\/management\/weblogic\/latest\/serverRuntime permet par exemple de r\u00e9cup\u00e9rer les m\u00e9triques de fonctionnement du serveur.<\/p>\n

Or, pour dialoguer avec l’API il faut \u00eatre authentifi\u00e9, ce qui semble normal pour \u00e9viter que n’importe qui acc\u00e8de \u00e0 ces informations ou d\u00e9clenchent inopportun\u00e9ment des actions sur les serveurs.<\/p>\n

Le probl\u00e8me est que cette authentification provoque la cr\u00e9ation d’une session HTTP au niveau du serveur.<\/p>\n

Le contexte web \u00ab\u00a0\/management\u00a0\u00bb est g\u00e9r\u00e9 par l’application web interne wls-management-services.war<\/p>\n

Le timeout de session est fix\u00e9 \u00e0 3600 secondes (1 heure) sur cette application web.<\/p>\n

En cons\u00e9quence et s’il on n’y prend pas garde, chaque appel vers l’API REST va cr\u00e9er une nouvelle session dans le serveur et donc consommer de la m\u00e9moire.<\/p>\n

Les tests que j’ai r\u00e9alis\u00e9 sur une version 12.2.1.3 montrent que les sessions HTTP sont d’une taille d’environ 1,7 Ko<\/p>\n

C’est pas \u00e9norme mais cet effet de bord est \u00e0 prendre en consid\u00e9ration si le nombre d’appels REST est important.<\/p>\n

Pour \u00e9viter la sur-multiplication des sessions il faut r\u00e9utiliser le cookie de session JSESSIONID qui sera renvoy\u00e9 par le serveur lors de la 1\u00e8re requ\u00eate.<\/p>\n

A noter \u00e9galement, que l’API ne propose pas de d\u00e9connexion pour supprimer (invalidate<\/em>) la session HTTP.<\/p>\n

Bonne lecture.<\/p>\n","protected":false},"excerpt":{"rendered":"

Depuis la version 12c, WebLogic Server expose certains de ces services au travers d’une interface RESTFUL. Vous pouvez consulter la documentation officielle pour avoir davantage d’informations sur le sujet. Ceux connaissant d\u00e9j\u00e0 les fondamentaux des API REST ont du \u00eatre surpris par le titre de l’article mentionnant les sessions HTTP. En effet, une architecture REST […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_monsterinsights_skip_tracking":false,"_monsterinsights_sitenote_active":false,"_monsterinsights_sitenote_note":"","_monsterinsights_sitenote_category":0,"footnotes":""},"categories":[4],"tags":[36,37,35,10,8],"class_list":["post-266","post","type-post","status-publish","format-standard","hentry","category-weblogic","tag-api","tag-management","tag-rest","tag-session-http","tag-weblogic-server"],"_links":{"self":[{"href":"https:\/\/corsaire-consulting.fr\/blog\/index.php\/wp-json\/wp\/v2\/posts\/266","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/corsaire-consulting.fr\/blog\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/corsaire-consulting.fr\/blog\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/corsaire-consulting.fr\/blog\/index.php\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/corsaire-consulting.fr\/blog\/index.php\/wp-json\/wp\/v2\/comments?post=266"}],"version-history":[{"count":3,"href":"https:\/\/corsaire-consulting.fr\/blog\/index.php\/wp-json\/wp\/v2\/posts\/266\/revisions"}],"predecessor-version":[{"id":270,"href":"https:\/\/corsaire-consulting.fr\/blog\/index.php\/wp-json\/wp\/v2\/posts\/266\/revisions\/270"}],"wp:attachment":[{"href":"https:\/\/corsaire-consulting.fr\/blog\/index.php\/wp-json\/wp\/v2\/media?parent=266"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/corsaire-consulting.fr\/blog\/index.php\/wp-json\/wp\/v2\/categories?post=266"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/corsaire-consulting.fr\/blog\/index.php\/wp-json\/wp\/v2\/tags?post=266"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}