RESTAssured ja Istuntokeksit

REST ja istunnot ovat aikalailla paradoksi. Mutta silti joskus löytää itsensä tilanteesta jossa tilattomat REST palvelut ovat tilallisen autentikoinnin takana, esim. JSESSIONID evästeellä seurattuna (Ja kyllä, Suomen Kielitoimisto suosittaa nykyisin Cookielle termiä eväste, aiemmin keksi, ja uskokaa tai älkää, alunperin Taikapipari). Jos vielä heikommin käy, edessä voi olla joku single-signon hirviö joka tokenien sijasta käyttää useampaa istunto-evästettä. Ja jotenkin pitäisi saada kirjautumisen jälkeen istunnot säilymään.

Jos kyseessä on vain yksinkertainen JSESSIONID case, alkaen RestAssured versiosta 2 sille on tuki valmiina, parillakin eri tavalla. Nopein tapa saada sessio-cookie lähetettyä edestakaisin on tähän tapaan:

RestAssured.filters(sessionFilter);

Tuo pitää huolen, että sessio-eväste kaapataan vastauksista, ja liitetään pyyntöihin. Toimii heittämällä jos nimi on JSESSIONID – kunhan vain pidät huolen siitä, että sessionFilter on kaikissa kutsuissa sama, esim. luomalla sen staattisena:

public static final SessionFilter sessionFilter = new SessionFilter();

Entä jos evästeen nimi ei ole JSESSIONID? No, sen voi helposti muuttaa RESTAssured konfiguraatiolla:

RestAssured.config = newConfig().sessionConfig(new SessionConfig().sessionIdName("KOTLINSESSIONID"));

Entä jos pitäisi puljata useampia tracking cookieita, ja niiden nimet muuttuvat välissä? No ei hätää, sen voi hoitaa omalla custom filterillä, tähän tapaan:

public class CookieResenderFilter implements com.jayway.restassured.filter.Filter {

  private Map<String, Object> cookiesMap = new HashMap<String, Object>();

  @Override
  public Response filter(FilterableRequestSpecification filterableRequestSpecification,
                         FilterableResponseSpecification filterableResponseSpecification,
                         FilterContext filterContext) {
    filterableRequestSpecification.cookies(cookiesMap);
    Response response = filterContext.next(
      filterableRequestSpecification,
      filterableResponseSpecification);
    Map<String, String> cookiesReceived = response.getCookies();
    if (cookiesMap.size() == 0 && cookiesReceived.size() > 0) {
      for (String key : cookiesReceived.keySet()) {
        cookiesMap.put(key, cookiesReceived.get(key));
      }
    }
    return response;
  }
}

Ja tuo rekisteröidään käyttöön kuten yllä, taas pitäen huolta siitä että kyseessä on aina sama instanssi, ei aina uusi – koska sen jäsenmuuttujia käytetään tiedon varastointiin testisession ajan.

Oikeastihan tilallisuus + REST rajapinnat ovat helvetin seitsemännen tason keksintö ja jo tätä artikkelia kirjoittaessa tuli likainen olo, mutta aina ei pääse valitsemaan työkalupakkiaan. Kun pääsee, käyttäkää BCRYPT Token headereita, ihmiset!

SOAPUI, autentikointi ja Groovy

Testasin taannoin SOAPUI:lla REST rajapintoja suorituskykytestimielessä. Kun rajapinnat olivat julkisia, homma on hyvin helppoa. Mutta kun rajapinta onkin autentikoinnin takana, edessä on perinteinen testityökalujen haaste: Miten kirjautua sisään siten että seuraavat kutsut menevät samaan sessioon?

No sehän riippuu autentikoinnin tavasta. SOAP UI:sta on kirjoiteltu artikkeleita joissa käydään läpi miten siihen voi tehdä mm. BASIC/DIGEST autentikoinnilla säädöt paikalleen, ja samoin on OAUTH-standardille palikoita. Mutta yleinen ratkaisu miten siirtää tavaraa pyynnöstä toiseen oli tässä yksinkertaisin. Tempun salaisuus on tehdä test caseen erillinen askel, jossa varastoidaan autentikoinnin tieto kontekstiin, josta sen voi myöhemmin pukata haluamaansa paikkaan, esim. http headeriin tms.

Eli sanotaan että askel 1 on määritetty olemaan REST kutsu nimellä ’login’, joka lähettää tunnusta ja salasanaa, ja vastaanottaa tokenin, esimerkissä nimellä ’identityToken’. Seuraava askel on avata SOAP UI:ssa test case, ja lisätä sinne uusi askel.(Add Step – Groovy Script).

Tänne kirjoitellaan koodi joka imaisee tokenin vastauksesta, esim. tähän tapaan:

// This script will grab authentication token and store it in testcase properties so it can be used later

xmlResponse = new XmlSlurper().parseText(context.expand( ’${login#ResponseAsXml}’ ))

assert xmlResponse.sessionId != null
assert xmlResponse.sessionId.toString().length() > 0
log.info(’Got ’ + xmlResponse.sessionId)
testRunner.testCase.setPropertyValue( ”authToken”, xmlResponse.sessionId.toString())

Eli pari huomiota tästä esimerkistä:

  • Tässä hyödynnetään SOAPUI:n ominaisuutta auto-konvertoida json xml muotoon – eli vastaus voi olla xml tai jsonia, kaikki käy
  • context.expand viittaa login-stepin sisältöön xml:ksi rutistettuna
  • Pseudo-xml kenttiin viitataan xmlResponse.xxx tapaan kuten yllä
  • log.info on tässä vain esimerkin vuoksi, sillä saa tulostusta
  • testcasen propertyyn lisätään authToken niminen arvo jossa on sessionid varastoituna

Tätä voi sitten vuorostaan käyttää missä haluaakin, esim. header kentässä tai asserteissa, tähän tapaan:

${#TestCase#authToken}

SOAPUI ja LOADUI ovat ihan metkoja kapistuksia joilla aika helposti pyöräyttää vähän integraatio/api/suorituskykytestejä.

JAX-RS ja Swagger: Helposti dokumentoity REST API

Hetken aikaa jo on tykyttänyt mietintämyssyn alla miten REST rajapintoja voisi helposti dokumentoida – WSDL kun sieltä uupuu (Ja WADL:ia ei kukaan halua). Kuitenkin pitäisi pystyä kertomaan ja rekisteröimään missä osoitteissa on palvelua, mitä ne tekevät, miten niitä kutsutaan, jne, muutenkin kuin testeillä ja esimerkeillä.

Törmäsin mukavaan jersey-yhteensopivaan laajennukseen nimeltä jersey-swagger. Sovitin tätä Glassfishin versioon, jossa pyörii Jersey 2, ja sainkin jotain aikaan. Tässä muistiinpanoja:

Käyttöönotto vaatii muutaman askelen: Ensiksi täytyy Mavenissä tai Gradlessa ottaa käyttöön swagger jersey versiolle kaksi. Samalla on tuikitärkeää määrittää pari exclusionia, tai serverille päätyy duplikaatteja hieman eri versioista ja tulee mukavia poikkeuksia logista. Tässä toimivaksi testattu dependency Glassfish neloselle:

 <dependency>
   <groupId>com.wordnik</groupId>
   <artifactId>swagger-jersey2-jaxrs_2.10</artifactId>
   <version>1.3.7</version>
   <exclusions>
     <exclusion>
       <groupId>org.glassfish.jersey.media</groupId>
       <artifactId>jersey-media-multipart</artifactId>
     </exclusion>
     <exclusion>
       <groupId>org.glassfish.jersey.containers</groupId>
       <artifactId>jersey-container-servlet-core</artifactId> 
     </exclusion>
   </exclusions>
 </dependency>

Hyvä tarkistaa tässä välissä että vanhat palvelut edelleen toimivat, jos niitä on. Seuraavaksi rekisteröidään Swagger servicet. Tämän voi tehdä xml:ssä – mutta itse käytän ResourceConfig-luokkaa ja annotaatioita:

@ApplicationPath("rest")
public class ApplicationConfig extends ResourceConfig {
public ApplicationConfig() {
packages("my.own.resources","com.wordnik.swagger.jersey.listing");
 }
}

Noin, sieltä aktivoituu tosiaan pari resurssiluokkaa, automaattisesti /rest/api-docs osoitteella. Seuraavaksi rekisteröidään Swagger servlet. Tämänkin voi tehdä annotaatioilla mutta kun sattui olemaan vielä web.xml (se on ainoa paikka jossa voi tehdä distributable-setin ha klusteriin) – tein sen siellä näin:

 <servlet>
 <servlet-name>JerseyJaxrsConfig</servlet-name>
 <servlet-class>com.wordnik.swagger.jersey.config.JerseyJaxrsConfig</servlet-class>
 <init-param>
 <param-name>api.version</param-name>
 <param-value>1.0.0</param-value>
 </init-param>
 <init-param>
 <param-name>swagger.api.basepath</param-name>
 <param-value>http://localhost:8080/rest/api-docs</param-value>
 </init-param>
 <load-on-startup>2</load-on-startup>
 </servlet>

Nyt alkaa jo melkein tapahtumaan. Seuraavaksi pitää varustaa ainakin yksi palvelu @Api-annotaatiolla, metodeille voi pistää @ApiOperation, ja parametreille ja paluuarvoille @ApiModel annotaatioita. Jotta saat jotain näkyviin tarvitset ainakin yhden @Api-annotaatiolla varustetun palvelun, jolla on ainakin yksi @ApiOperation annotaatiolla varustettu operaatio.

Tähän tapaan:

@Path("/pet")
@Api(value = "/pet", description = "Operations about pets")
@Produces({"application/json", "application/xml"})
public class PetResource {
  ...
@GET
@Path("/{petId}")
@ApiOperation(value = "Find pet by ID", notes = "More notes about this method", response = Pet.class)
@ApiResponses(value = {
  @ApiResponse(code = 400, message = "Invalid ID supplied"),
  @ApiResponse(code = 404, message = "Pet not found") 
})
public Response getPetById(
    @ApiParam(value = "ID of pet to fetch", required = true) @PathParam("petId") String petId)
    throws WebApplicationException {
@ApiModel(value = "A pet is a person's best friend")
@XmlRootElement(name = "Pet")
public class Pet {
  @XmlElement(name = "status")
  @ApiModelProperty(value = "Order Status", required=true, allowableValues = "placed,approved,delivered")
  public void setStatus(String status) {
    this.status = status;
  }
  public String getStatus() {
    return status;
  }

Sitten voitkin käynnistellä serverin, ja kokeilla mitä löytyy kontekstin alta osoitteella /api-docs, /api-docs/myservicename, jne – tässä tietysti myservicename on joku palvelu johon olet noita Swagger-annotaatioita ripotellut.

Tuolta löytyy myös esimerkkiä live-sisällöstä, niin kauan kuin se tietysti on pystyssä:

http://petstore.swagger.wordnik.com/api/api-docs

Näyttäisi tämmöiseltä:

{"apiVersion":"1.0.0","swaggerVersion":"1.2","apis":[{"path":"/pet","description":"Operations about pets"},{"path":"/user","description":"Operations about user"},{"path":"/store","description":"Operations about store"}],"authorizations":{"oauth2":{"type":"oauth2","scopes":[{"scope":"write:pets","description":"Modify pets in your account"},{"scope":"read:pets","description":"Read your pets"}],"grantTypes":{"implicit":{"loginEndpoint":{"url":"http://petstore.swagger.wordnik.com/oauth/dialog"},"tokenName":"access_token"},"authorization_code":{"tokenRequestEndpoint":{"url":"http://petstore.swagger.wordnik.com/oauth/requestToken","clientIdName":"client_id","clientSecretName":"client_secret"},"tokenEndpoint":{"url":"http://petstore.swagger.wordnik.com/oauth/token","tokenName":"auth_code"}}}}},"info":{"title":"Swagger Sample App","description":"This is a sample server Petstore server.  You can find out more about Swagger \n    at <a href=\"http://swagger.wordnik.com\">http://swagger.wordnik.com</a> or on irc.freenode.net, #swagger.  For this sample,\n    you can use the api key \"special-key\" to test the authorization filters","termsOfServiceUrl":"http://helloreverb.com/terms/","contact":"apiteam@wordnik.com","license":"Apache 2.0","licenseUrl":"http://www.apache.org/licenses/LICENSE-2.0.html"}}

Törmäsin myös toiseen aika metkaan standardiin – ALPS. Sitä näyttäisi osaavan Spring Framework hyvin, mutta ainakan nyky-jerseystä ei löytynyt helppoa ratkaisua siihen. Pidän tätäkin kuitenkin silmällä. Looking good!

http://www.dzone.com/links/r/spring_data_rest_now_comes_with_alps_metadata.html

http://alps.io/

Näistä linkeistä löytyy vähän lisää ideoita. Varovaisuutta vanhemman Swagger-version kanssa!

https://github.com/wordnik/swagger-core/wiki/Java-JAXRS-Quickstart

 

 

JFokus 2/4 – tarinoita Tukholmasta

No niin, edelleen ollaan siis Tukholmassa ja JFokus konferenssissa. Osallistujia täällä on hieman yli 1100, joista se satakunta tuli Suomen puolelta aamulautalla.

Aamun avasi räväkästi Henrik Ståhl Oralelta, ja mitä keynoteihin tulee tämä oli piristävää vaihtelua. Henrik puhui Oraclen ahneudesta ja arvosteli Oraclen toimintaa Machiavellin silmin 😉 Toden sanoakseni esitys oli hyvin huumoripitoinen, yllättävänkin suora ajoittain, ja siinä vastattiin taas hyvin kysymyksiin joita Java kehittäjät ovat pohtineet ja myös julkisesti ruotineet. Javan ja Oraclen näkymiä luotailtiin kolmesta näkökulmasta: Niccolo Machiavellin, Duken, sekä rahan jumalan Mammonin.

Machiavellillä on muuten ollut jo aikanaan PR puoli hyvin hallussa, monet viisaudet pätevät (entistä enemmän) tänä päivänä. Pelottavaa.. Oli miten oli, aamu oli kiintoisa ja rentouttava. Esityksen lopussa tuli myös esille roadmap ajatuksia aina Java 9:ään asti. Nyt kannattaa kaikkien kynnelle kykenevien pistää ehdotuksia HotSpot + JRockit JVM yhdistelmän nimeksi, tai muuten sen nimeksi tulee Fusion JVM 😉

Esityspuolelta mieleen jäi Oraclen standin Brainwaves peli jossa piti aivonsa alfa aallot rentouttamalla saada kuula leijumaan ilmassa mahdollisimman pitkään. Tiedä sitten onko hyvä asia mutta kun pistin anturit päähäni kuula pomppasi melkein samantien kattoon, liekö sitten tuo aivojen tyhjentäminen vahva puoleni. Valitettavasti kuulan liikkeistä innostuminen toi aktiviteetia ja tipautti kuulan maahan. Paikallinen ennätys oli 22 sekuntia leijuntaa (eli tyhjä pää), ja kuulemma joiltakuilta onnistuu pari minuutiakin. Itseä kun nuo UI puolen asiat aina kiinnostavat, ja kun en usko että monitori, hiiri ja näppäimistö on se lopullinen ratkaisu tietokonetta käskyttäessä, niin tällaiset poikkeukselliset ratkaisut kiinnostavat. Tuossa linkit vielä Neurosky laitteeseen ja yleensä aiheesta: http://www.neurosky.com/ http://gajitz.com/mind-games-four-games-you-control-with-your-brain/

Brainwaves anturien oikea käyttö on liikkumisrajoitteisten ihmisten käyttöliittymissä, ja keskittymällä kuulaa pystyikin ohjaamaan. Kontrolli oli vielä omasta yrityksestä kaukana mutta eiköhän tuossa muutamassa päivässä olisi jo vauhdissa. May the Force be with you!

Sieltä sitten takaisin maan pinnalle. Eric Evans puhui ketterästä DDD:stä, Domain Driven Developmentista, ja sen sudenkuopista ja parhaista käytännöistä. Toistuvana kaavana suomalaisten firmojen kanssa olen aika ajoin kuullut miten ketteriä menetelmiä kuten Scrum:ia kirotaan alimpaan manalaan ja haukutaan miten ne eivät toimi. Useimmiten kun kuulen tällaista ja kyselen lisää, selviää kaksi asiaa aina toistuvasti: 1) Projektissa ei olekaan Product Owneria ja piirteiden priorisointia, vaan kyseessä onkin Scrummerfall eli on tehty speksit, on tehty suunnittelu alussa, ja sitten ohjelmoijatiimille sanotaan että olkaa ketteriä. Ja 2) on aamupalaverit ja iteraatiot, mutta toteutuksen osalta on lähinnä omaksuttu että ei suunnitella, eikä dokumentoida varsinkaan, eli jätetään suunnittelu ja testaus kokonaan pois iteraatiosta ja hakataan vain päätä seinään tekemällä lyhytnäköistä koodia jota ei ehditä saamaan iteraatiossa edes valmiiksi. Tässä esityksessä ei suoranaisesti menty Agile menetelmiin tai prosesseihin, vaan käytiin läpi miten DDD:tä voi tehdä hyvinkin luonnollisesti keskustelujen kautta.

Tähän väliin hieman kehuja Vaadin frameworkille tehdystä seminaarin aikatauluohjelmasta, ainakin vielä osoitteessa http://www.jfokus.se/jfokus/page.jsp?id=vschema ja http://code.google.com/p/devoxx-schedule-2010/ – varsin näppärä ja toimiva kontrolli ja sovellus. JFokushan fiksusti julkaisi REST rajapinnat joilla seminaaritietoja saa esille.. Ihan piruuttani koodasin itsellenikin niiden varaan Android mokkulan, joskin jaossa oleva virallinen versio on huomattavasti parempi. Mutta oma on aina oma vaikka onkin ruma.

Hupaisa yksityiskohta: IPhonellekin oli tehty seminaarisofta, mutta se ei ole ehtinyt hyväksyntäprosessien läpi vielä joten iPhone mistajat… sorry! 😉 Henrik Ståhl muuten lipsautti aamun keynotessaan miten Javan tavoite on pyöriä myös iPhonessa tulevaisuudessa, saapa nähdä oliko tässä konkretiaa vai unelmointia..

Google App Engine pilvipalvelu ja Java EE 6, osa 4

Silmäilin mielenkiinnolla miten Java EE 7 tulee koskemaan pääteemana pilvipalveluita; Tekisi hyvää saada yhteistä rajapintaa myös tämän osalta, jolloin ainakin teoriassa pilvipalveluista tulisi vapaammin siirettäviä ja kilpailutettavia, ja vältettäisiin nykyinen vahva vendor lock-in.. Aika näyttää miten tässä käy.

Itse päädyin tekemään muutoksen oman pilvipalveluni arkkitehtuuriin. Siinä missä homma alkoi Solakka Java-periaatteella, totesin että vaikka JSF 2 on paljon parannettu versio aiemmasta, tekniikkademosta saa paljon mielenkiintoisemman jos korvaan sen RESTful web service tekniikalla ja suomalaisella Vaadin AJAX frameworkillä.

Valitsin toteutusalustaksi referenssitoteutuksen eli Jersey JAX-RS alustan. Sain sen käyttöön Mavenin  pom.xml:ssä näin:

<!-- Turn on Jersey JAX-RS -->
<dependency>
<groupId>com.sun.jersey</groupId>
<artifactId>jersey-server</artifactId>
<version>1.4</version>
</dependency>
<dependency>
<groupId>com.sun.jersey</groupId>
<artifactId>jersey-client</artifactId>
<version>1.4</version>
</dependency>
 
<dependency>
<groupId>com.sun.jersey</groupId>
<artifactId>jersey-json</artifactId>
<version>1.4</version>
</dependency>
<dependency>
<groupId>com.sun.jersey.contribs</groupId>
<artifactId>jersey-multipart</artifactId>
<version>1.4</version>
</dependency>

Eli muutama dependency lisää. Lisäksi web.xml:ssä piti ottaa Jersey servlet käyttöön ja kertoa mitä pakettia skannata resurssien osalta, tähän tapaan:

<!-- JERSEY support -->
<servlet>
<servlet-name>Jersey Web Application</servlet-name>
<servlet-class>com.sun.jersey.spi.container.servlet.ServletContainer</servlet-class>
<init-param>
<param-name>com.sun.jersey.config.property.packages</param-name>
<param-value>fi.tieturi.pilvenveikko.services</param-value>
</init-param>
<load-on-startup>1</load-on-startup>
</servlet>
<servlet-mapping>
<servlet-name>Jersey Web Application</servlet-name>
<url-pattern>/resources/*</url-pattern>
</servlet-mapping>

Ja siitä se sitten lähti. REST filosofian mukaan muokkaan palveluita CRUD tyyliin joten jatkossa voi luoda tätä kautta WorkUnit, Person, ja Goal yksiköitä, hakea ja päivittää ja poistaakin niitä, http url osoitteilla.

Pari pikku knoppiakin tuli vastaan. Google App Enginen JPA toteutus ei haekaan tietoja aina heti vaan käyttää lazy load periaatetta. Näin on tarpeen varmistaa että kaikki tiedot on kannasta saatu ennen kuin niitä xml:ksi marshalloidaan . Tämän voi hoitaa vaikkapa size-metodia kutsumalla. Tässä maistiainen Resource luokastani:

package fi.tieturi.pilvenveikko.services;
import fi.tieturi.pilvenveikko.domain.WorkUnit;
import fi.tieturi.pilvenveikko.util.EMF;
import java.util.List;
import javax.persistence.EntityManager;
import javax.persistence.Query;
import javax.ws.rs.GET;
import javax.ws.rs.Path;
import javax.ws.rs.Produces;
@Path("/workUnit")
public class WorkUnitResources {
  @GET
@Path("/findAll")
@Produces("text/xml")
public List<WorkUnit> getWorkUnits() {
EntityManager em = null;
try {
em = EMF.get().createEntityManager();
Query q = em.createQuery("SELECT wu FROM WorkUnit wu ORDER BY wu.workDate");
q.setMaxResults(200); // limit to max 200 results
List<WorkUnit> results = q.getResultList();
results.size(); // this is a hack to wait until results are all there
return results;
} finally {
if (em != null) {
em.close();
}
}
 }

@GET
@Path("/read/{workUnitId}")
@Produces("text/xml")
public WorkUnit getWorkUnitById(@javax.ws.rs.PathParam(value="workUnitId") long workUnitId) {
EntityManager em = null;
try {
em = EMF.get().createEntityManager();
WorkUnit result = em.find(WorkUnit.class, workUnitId);
return result;
} finally {
if (em != null) {
em.close();
}
}
}
}

Ja siinä se. Ensi kerralla voisin jutella vaikkapa Vaadin frameworkin käyttöönotosta ja piirteistä ja pilvivirityksistä.