favornokia

D.
KaeliandK.
Sachs(Eds.
):SPECBenchmarkWorkshop2009,LNCS5419,pp.
439–450,2009.
Springer-VerlagBerlinHeidelberg2009DesigningWeb-BasedMobileServiceswithRESTClaudioRivaandMarkkuLaitkorpiNokiaResearchCenter,P.
O.
Box408,FIN-00045NOKIAGROUP,Finland{claudio.
riva,markku.
laitkorpi}@nokia.
comAbstract.
TheWebisemergingasthefavoriteplatformfordeliveringapplica-tionsandservices.
TheRESTarchitecturalstylecomprisesthekeyprinciplesbehinditsdesignandsuccess.
WhileRESTisoriginallydefinedinthecontextofpublishinghypermediadocuments,itisbecomingapopularmethodforim-plementingWebservicesaswell.
Thegoalofthispaperistoexploretheprin-ciplesoftheRESTstyleforbuildingmobileservicesandtoaddressthemobilespecificconstraints.
Wepresentthedesignmethodthatwehavefollowedforbuildingabasicphotostorageservice.
OurpreliminaryevaluationconfirmsthatRESTisaflexibleandextensibleapproachforbuildingmobileservices.
Keywords:Softwarearchitectures,mobileservices,serviceorientedarchitec-tures,weborientedarchitectures,REST.
1IntroductionNewcompellingmobileservicesareexpandingthecapabilitiesofmobiledevicesbesidesthetraditionalservicesofvoiceandshortmessaging.
Nowadaysmodernmo-biledeviceshavebuilt-insupportforseveralmobileserviceslikewebbrowsing,mo-bileemail,mobilesearch,photosharing,newsreaders,internetradioandnavigation.
ThepromiseofthemobileInternetisturningintorealityformanyconsumers.
Insomecases,themobileservicesaretightlybundledwiththedevicesinordertomaximizetheiruserexperience,e.
g.
BlackberryResearchinMotion's(RIM)pushemailservice,NokiaN-GageArenaandNokiaS60'ssupportformobilesearchandphotosharingwithFlickr.
WiththeavailabilityoffastandconvenientmobileInter-net,weexpectthatmobileserviceswillrepresentasignificantvalue-addingelementoffuturedevices.
TheWorldWideWebisemergingasthefavoriteplatformfordeliveringapplica-tionsandservices.
TheWeb2.
0phenomenonisexploitingthewebbrowserasacross-platformruntimeenvironmentforshippingandexecutingapplications.
Special-izedlibraries(e.
g.
Ajax)andframeworks(e.
g.
RubyonRails)havebeendevelopedforfacilitatingthecreationofinteractivewebapplications.
TheWebisalsobecomingthepreferredplatformfordeliveringservicestothirdparties.
InternetcompaniesopentheirfunctionalityandtheirdatatotheexternaldevelopersthroughpublicinterfacesimplementedwithWebservices.
Thesepublicinterfaces,typicallycalledOpenAPIsorWebAPIs,arekeyenablersoftheWeb2.
0phenomenon.
440C.
RivaandM.
LaitkorpiTherearetwodominantparadigmsforcreatingWebAPIs,namelySOAP/WS-*andREST.
SOAPisanXMLbasedprotocolforexchangingmessagesoveracom-puternetwork,typicallytunnelingoverHTTP,andisthefoundationforthemorecomplexWebServicesstack,alsoknownasWS-*[10,11].
SOAPprovidesdifferenttypesofmessagingpatterns,buttheremoteprocedurecalliscommonlyusedwhenbuildingOpenAPIs.
ASOAPbasedOpenAPItypicallyprovidesasetofremoteoperationsthatcanbeinvokedovertheWeb.
REST(RepresentationStateTransfer)followsadifferentphilosophythanSOAPbyfocusingondatainsteadofoperations.
RoyFielding,oneoftheprincipalauthorsoftheHypertextTransferProtocol(HTTP)[2],coinedthetermREST1inhisdoctoraldissertation[1].
RESTisanarchitecturalstylederivedfromtheWeb,anditsarchitec-turalelementsandconstraintsaimatcollectingthefundamentaldesignprinciplesthatenablethegreatscalability,growthandsuccessoftheWeb.
RESTisoriginallyde-finedinthecontextofpublishinghypermediadocumentsbutithasbecomeapopularmethodforpublishingWebservicesasaWeb-friendlyalternativetoSOAP.
RESTisprimarilyfocusedondefiningandaddressingwebresources(likedocumentsandimages)andformanagingtheirrepresentations.
AlthoughthereisonlyoneversionofRESTdefined,itdoesnotmeanthateverysystemissupposedtobeequallyRESTful.
Therefore,theconstraintsofRESTshouldbetakenasatoolkitthathelpsthearchitectidentifythebenefitsorcosts,dependingonwhethertheactualrequirementsfittheconstraints.
ThegoalofthepresentresearchistoinvestigatehowtoapplytheprinciplesoftheRESTfuldesigntothedevelopmentofmobileservices.
Inparticular,ourfocusistoanalyzethebenefitsandlimitationsofRESTinamobilecontextandtoelaborateaproperdesignprocess.
DesigningRESTservicesisaboutmodelingresourcesthatarepublishedontheWebandthefunctionalityisimplementedwithalimitedsetofop-erationsonthoseresources.
Thedesignprocessresemblesthedata-drivendesignprocesses(e.
g.
fordatabases).
Inthispaper,wepresentourpreliminaryworkofde-signingRESTservices.
First,wepresentthekeyrationaleandconstrainsofRESTdesigninamobileenvironment.
Then,wepresentourdesignprocessandweapplyittothecasestudyofdesigningaphotostorageservices.
Finally,weconcludewithapreliminaryevaluation.
2MobileServiceswithREST:RationaleandConstraintsMobileservicesallowuserstoaccessnetworkservicesthroughtheuserinterfaceofamobiledevice.
Theyconsistofaclientapplication,theclientcomponentthatpro-videstheuserinterfaceonthemobiledevice,andaservicebackend,theservercom-ponentinthenetworkthatprovidestheremotefunctionality.
Theimplementationoftheclientapplicationheavilydependsonthecapabilitiesofthemobiledeviceandtheavailablerun-timeenvironments.
Often,themobilesoft-waredevelopermustspecializetheclientapplicationstothevariousclientsinordertotakefulladvantageofthedevicespecificfeatures[5].
Theclientapplicationalso1TherearedifferentinterpretationsofREST.
Unlessotherwisespecifiedinthispaperwerefertoatrulyresource-orientedapproach,oftenreferredasRESTful.
DesigningWeb-BasedMobileServiceswithREST441needstoefficientlyinteractwiththebackendinordertofetchthedatathatispre-sentedintheuserinterface.
Thereareseveralmotivationstodesignthebackendac-cordingtotheRESTstyle:Itprovidesauniformmethodforaccessingtheresourcesindependentlyoftherun-timeenvironment(native,Java,Python,etc).
AnyclientthatsupportstheHTTPprotocoliscapableofaccessingtheRESTserviceswithouttheneedofanyadditionalmessagingframework.
Therepresentationofaresourcecanbenegotiatedatrun-timebetweentheclientandtheserver.
Thisenablesustosupportmobileoptimizedvariantsofthere-sourcesaccordingtotheneedsofthedevice.
TheRESTprinciplesfavorscalabilityandfastresponsetimes(e.
g.
throughcach-ing).
Thisisanimportantpointformobileservicesthatpotentiallyhaveahugeuserbaseofbillionsofusers.
Scalabilityisoftenahardtoreachqualityifnotproperlyaddressedearlyinthedesign.
However,themobileenvironmentposesadditionalchallengesandconstraintsoverthetypicalRESTdesign.
Wesummarizethembelow:Networklatency:mobiledatanetworks(2G,EDGE,3G)areoptimizedforcon-tentdownload.
Thebandwidthisoftensufficientformostofthescenarios(likevideostreaming),butthenetworklatencyisstillamajorissue.
Eveniffuturenetworksbeyond3G(e.
g.
HDSPA,WiMAX)willminimizethisproblem,areli-ablemobileserviceshouldmakefewassumptionsabouttheunderlyingdatanet-work.
Optimizingforhighlatencynetworkisakeyrequirementforsuccess.
Theroundtriptimeforsendingarequestandreceivingaresponsecanbeashighastwoseconds.
Toavoidperformancebottlenecks,thenumberofmessageex-changeswiththeservermustbekeptattheminimum.
ThisrequirementisoftenconflictingwithRESTservicesdevelopedforlowlatencynetworks.
Dataformats:verbosedataformats(e.
g.
XML)areslowtotransferandtoparse.
Mobiledevicesrequirelightweightformats.
Compactbinaryformatsareoftentheoptimalsolutionbuttheycompromisetheserviceinteroperability.
Often,thetradeoffisbetweenaproprietaryoptimizationandaninteroperablestandard.
Cachingpolicy:toreducethenetworktrafficthemobileservicesmustcachethedataonthedevicememory.
Cachingcanhappeneitherattheprotocollevel(e.
g.
theHTTPresponses)orattheapplicationlevel(e.
g.
theactualdata).
Offline/onlinebehavior:irregularnetworkconnectivityistypicalformobiledevices.
Mobileservicesmustdefineastrategyforsupportingofflineoperations.
Thinvs.
thickclients:howmuchlogicresidesontheclientandontheserver.
3DesigningRESTServicesThecoreentitiesoftheRESTdesignarethewebresources.
TodesigntheAPIswefollowadata-drivendesignprocessthatstartsbymodelingthedomainoftheAPIs.
Inthefollowingsectionswedescribeourbasicdesignprinciples,thedesignprocessandthestructureoftheRESTAPI.
442C.
RivaandM.
Laitkorpi3.
1DesignPrinciplesThebasicarchitecturalstyleisRESTwiththeHTTP.
ThefunctionalityisdefinedintermsofresourcesthataremanipulatedviaHTTPasanapplicationprotocol.
Aresourceisanentitythathas:nameandaddressidentifiedbyaURI[3]onestateatatimedefinedbyasetofattributesandtheirvaluesatleastonerepresentationthatencodethecurrentstateinaparticularcontenttypeTheallowedactionsontheresourcesarebasedontheHTTPprotocolwiththefol-lowingsemantics:GET:retrievesarepresentationofaresource.
Thisoperationissafewithnochangesthataclientcouldbeheldaccountablefor.
PUT:rewritesaresourcewithanewstatethatisenclosedintherequest.
Thisop-erationisidempotent(requestcanbere-processedwiththesamefinalstate).
POST:appendstheentityenclosedintherequesttotheresource.
Anewresourcemightbecreated.
Thisactionreturnseitherthelocationofthecreatedresourceortheresourcerepresentationafterappending.
Thisoperationisnotidempotent.
DELETE:removesthemappingbetweenaresourceanditsURI,thusmakingtheresourceinaccessible.
Thisoperationisidempotent.
EachrequestisauthenticatedindependentlyusingthestandardHTTPauthorizationheader.
Hence,thereisnoneedforsessioncontrolandcookies.
TheaccesscontrolforaresourceisconductedattheURIlevel.
Concerningthedataobjects,wesupporttheexchangeoftwotypesofstructureddata:containers(e.
g.
acollectionofphotos)andsingleitems(e.
g.
animage).
Besidesthestandardcontenttypesformedia(MIMEtypes[6]),wesupportcontenttypesforstructureddatafordifferentapplications:ATOM(application/atom+xml):widelypopularXMLbasedformatforblogsandmash-ups[7,8]JSON(application/json):lightweightformatforstructureddata[9]binaryJSON(application/x-bjson):ourownextensiontoJSONformattosupporttheexchangeofbinarydata.
WealsodefineadecorationmechanismforclientstocontroltheexactcontentofthemessagebodyoftheHTTPresponses.
IntheheaderoftheHTTPrequest,wecanaddacustomheadercalledx-decorationsthatcontainacommaseparatedlistofdecorationstobeappliedtotheresponse.
Wehavedefinedthefollowingdecorations:xlink-id:addbasicidentifierlinkstoobjectsxlink:addsallavailablelinkstoobjectsitem(id|summary|full):controlstheverbosityoftheitemswhenlistedinacontainerinline()=:outputsanoptimizedresponsethatincludestheassociateddatainonesinglerequest-responsecycle.
TheoutputDesigningWeb-BasedMobileServiceswithREST443formatdependsonthecontenttypeoftheresource.
ForJSONandXMLweusemultipart/related,forbinaryJSONandATOMweinlinethedatainplace.
Thecanbeanyoftheallowedcontenttypesofthelinkedre-source(e.
g.
image/jpg).
Thecanbeanyofthelinknamespub-lishedbytheresource(e.
g.
tn_tiny)3.
2DesignProcessDesigningRESTservicesinvolvemodelingwebresourcesandtheirURIs.
Therefore,wefollowadata-drivenapproachthatissummarizedinthreesteps:1.
Developingtheabstractdatamodel.
ThefirststepistoidentifytheconceptsandtheirassociationsthatarepartoftheAPI.
Forthistask,wefollowthetraditionaltechniquesofobject-orientedanalysisanddesign,focusingonalltherelevantnounsintheproblemdomain.
2.
Derivingthecoreresourcemodel.
Basedontheabstractdatamodel,weidentifytheprimaryresourcesoftheRESTdesign,i.
e.
thecentralconceptsoftheAPI.
Wedistinguishbetweentwotypesofresources:containers(collectionsofitems)anditems.
Besidestheprimaryresources,wecanalsoidentifythesecondaryresourcesthatcanbeaccessedfromtheprimaryresourcesthroughtheirassociations.
3.
DesigningtheURIspaceoftheAPI.
ThefinalstepistodefinetheURIspaceoftheAPI.
ForeachresourcewedefinetheURI,allowedmethods,contenttypes,andlinkstootherresources.
ThestructureoftheAPIisdescribedinthenextsection.
3.
3APIStructureThestructureoftheAPIisdocumentedusingfourelementsthataredescribedbelow:URIspace.
Eachresource(eitheracontaineroranitem)isaddressedbyoneURI.
Thenamecontainmentimpliesstrongsub-resourcerelationship.
Weusethefol-lowingsyntax:.
.
///where::encodestheowneroftheresource,suchasuser"john":encodestheprimaryresource,suchas"pho-tos"or"photo":encodestheassociationsfromtheprimaryresources,suchas"tagsofaphoto":querystringformultidimensionalprojections.
Methodsandcontenttypes:thisdescribestheavailableinteractionsonthere-sourcesandthesupportedcontenttypesLinks:traversableconnectionsfromoneresourcetoanother.
Itisacombinationofaname(semantics)andaURI(concreteaddress)Representations:actualdatacontentoftheresource444C.
RivaandM.
Laitkorpi4ExampleofRESTAPIforPhotosAsacasestudywehavedesignedthepotentialRESTAPIforaphotostorageservice.
Theserviceshouldprovidethefunctionalityforuploadingnewphotos,taggingthem,organizingthemintofoldersandassigningproperties.
Therearemanysimilarser-vicesontheWebthatprovideanAPIforstoringphotos:Flickr2andSmugmug3asexamples,buttheyareclearlyoperation-centricandonlyaccidentallyRESTful.
ThegoalofourcasestudyistodesignaphotostorageservicethatfollowstheRESTprin-ciplesandisusablefrommobiledevices.
Wedescribethedatamodel,thelistofwebresourceandseveralusecasestoaccesstheservice.
4.
1DataModelTheFigure1showsthesimpledatamodelforthephotostorageserviceandtheirattributes.
Wehaveincludedthefollowingconcepts:User:theauthenticateduserofthesystem.
EachuserhasauniqueloginnamePhoto:thedataobjectforaphoto.
Eachphotohasauniqueid.
Bag:auser-specificlabelforgroupingphotoobjectsinalbumsTag:apubliclydefinedlabelthatcanbeassociatedtoaphotoobjectContent:theactualbinaryrepresentationofthephoto(e.
g.
thejpgfile)Attr:anattributethatassignsavaluetoapropertyProp:apropertydefinitionwithsemantics,definedbyascopeandaname.
Tn:thebinaryrepresentationofathumbnailofaphoto.
Attr-prefix-nameBag-nameContentTag-nameTn-sizeUser-loginnamePhoto-idProp-prefix-name1*1***111*1****1Fig.
1.
AbstractdatamodelofthePhotoAPI4.
2CoreResourcesFromthedatamodelwecandirectlyderivethecoreresourcesoftheRESTAPI.
Belowwelistthecoreresources:PrimaryresourcesContainers:Photos,Tags,Bags,PropertiesItems:Photo,Tag,Bag,PropertySecondaryResourcesContainers:Thumbnailsofaphoto,Attributesofaphoto,Tagsofaphoto,BagsofaphotoItems:Content,Thumbnail,Attribute2http://www.
flickr.
com/services/api3http://www.
smugmug.
comDesigningWeb-BasedMobileServiceswithREST4454.
3APIStructureBasedonthecoreresourcemodel,wedefinethestructureoftheURIs.
Table1liststheURIsoftheresourcesandTable2documentsthesemanticoftheHTTPactions.
Table1.
StructureoftheAPIforPhotosURIOwnershipPrimaryprojectionAssociationDescriptionPhotos/users/{name}/photosPhotosforuser{name}(container)/users/{name}/photos/recentRecentphotosfor{name}(container)/users/{name}/photos/{photo-id}Photoitem/users/{name}/photos/{photo-id}/contentPhotocontentof{photo-id}/users/{name}/photos/{photo-id}/tns/tinyPhotothumbnail(50x50)/users/{name}/photos/{photo-id}/tns/smallPhotothumbnail(100x100)/users/{name}/photos/{photo-id}/tns/mediumPhotothumbnail(200x200)/users/{name}/photos/{photo-id}/tns/largePhotothumbnail(400x400)/users/{name}/photos/{photo-id}/tns/custom/{xsize};{ysize}Photothumbnailxsizexysize/users/{name}/photos/{photo-id}/attrsPhotoattributesfor{photo-id}(con-tainer)/users/{name}/photos/{photo-id}/attrs/{attr-prefix}/{attr-name}Photoattribute/users/{name}/photos/{photo-id}/tagsTagsfor{photo-id}(container)/users/{name}/photos/{photo-id}/tags/{tag-name}Phototag/users/{name}/photos/{photo-id}/bagsBagsfor{photo-id}(container)/users/{name}/photos/{photo-id}/bags/{bag-name}PhotobagTags/tagsAlltags(container)/tags/{tag-name}Tagitem/tags/{tag-name}/photosAllphotoswithtag{tag-name}(con-tainer)Bags/users/{name}/bagsAllbagsforuser{name}(container)/users/{name}/bags/{bag-name}Bagitem/users/{name}/bags/{bag-name}/photosAllphotosinbag{bag-name}(con-tainer)Properties/propsPublicproperties(container)/props/{prop-prefix}/{prop-name}Publicproperty446C.
RivaandM.
LaitkorpiTable2.
Supportedmethodsandcontent-typesfortheresources.
Unlessotherwisespecifiedallthemethodssupportthefollowingcontent-types:application/json,application/atom+xml,application/x-bjson.
ResourceMethodContent-typeDescriptionGETRetrievesthearrayofphotosPhotos(container)POSTimage/jpegAppendsanewphotoRecentphotos(container)GETRetrievesthearrayofrecentphotosGETRetrievesthephotoitemPUTReplacesthecontentoftheitemPhotoitemDELETERemovestheitemGETimage/jpegRetrievestheimagefilePhotocontentPUTimage/jpegReplacestheimagefilePhotothumbnailGETimage/jpegRetrievesthethumbnailfileGETRetrievesthearrayofattributesPhotoAttributes(container)POSTAddsanewattributetoaphotoGETRetrievesthevalueofanattributePhotoAttributePUTUpdatesthevalueofanattributeGETRetrievesthearrayoftagsTags(container)POSTAddanewtagtoatagcontainerGETRetrievesthetagdataPUTUpdatesthetagdataTagitemDELETERemovesthetagGETRetrievesthearrayofbagsBags(container)POSTAddsanewbagtoabagcontainerGETRetrievesthebagdataPUTReplacesthebagdataBagitemDELETERemovesthebag(butnotthecon-tent)GETRetrievesthearrayofpropertiesProperties(container)POSTCreatesanewpropertyGETRetrievesthedataaboutapropertyPUTUpdatesapropertyPropertyitemDELETERemovesaproperty4.
4UseCasesHowtoAccessthePhotoAPIUploadingaphotoTheusercanuploadaphotobysendingaPOSTrequesttoaPhotocontainer(e.
g.
/users/mary/photos)thebinarydatathatcontainsthejpgimageofthephoto.
Ifsuccessful,theservicesreplieswiththemessage"201Created"andtheLoca-tionheadercontainsthelinktothecreatedresource.
FetchingthelistofphotosTheusercanfetchthelistofphotosstoredinthesystemwithaGETrequestontherootPhotocontainer(e.
g.
/users/mary/photos).
TheresponseinJSONformatisanarraywiththeIDsofthephotos:DesigningWeb-BasedMobileServiceswithREST447{"photos":{"photo":[{"id":169},{"id":170},{"id":171},{"id":172},{"id":173},{"id":174},{"id":175},{"id":176}],"total":8,"start":0,"count":20}}Bypassingtheinlineheaderintherequesttheusercanrequestadditionalinforma-tiontobeaddedintheresponse.
Forinstance,wecaninlinethethumbnailsbyaddingtheheader:x-decorations:inline(image/jpeg)=tn_tiny.
TheresponseisamultipartmessagecontainingtheJSONdataandthethumbnails.
Fetchingthecontent/thumbnailofonephotoTheusercanfetchthecontentofonephotowithaGETrequestonthePhotoresource(e.
g.
/users/mary/photos/169/content).
Theresponseisthebinarydataofthejpegimage.
ThethumbnailcanberetrievedfromthesuitablethumbnailURI(e.
g.
/users/mary/photos/169/tns/small).
TaggingphotosBecauseasingletagissimplylikealabel,theusercanaddanewtagtoaphotobysendingaPUTrequesttoanon-existentTagresourceofthePhoto(e.
g.
/users/mary/photos/169/tags/Holiday).
Alternatively,theusercanuploadmultipletagsbyusingaPOSTrequestontheTagscontainerresourcewiththebodycontainingthetagnamesinJSONformat(e.
g.
{"tags":{"tag":[{"name":"Holiday"},{"name":"Maledives"}]}})TheusercanfetchthelistofallthephotoswithaparticulartagbysendingaGETrequesttotheTagresource(e.
g.
/tags/Holiday/photos).
Theresultisanarrayofphotos:{"photos":{"photo":[{"id":169},{"id":170}],"total":2,"start":0,"count":20}}Theusercanun-tagaphotosendingaDELETErequesttotheTagresourceofthePhoto(e.
g.
/users/mary/photos/169/tags/Holiday).
AttachingthegeolocationattributetoonephotoTheusercandefinenewpropertiesforthePhotoresourceandattachtheattributestoaparticularPhoto.
Inthiscaseweneedtodefineanewpropertyforstoringthegeolocationofaphoto(e.
g.
theproperty/loc/coord).
First,wesendaPOSTrequesttothePropertiescontainer(/props)withthenewpropertytocreate:{"prop":[{"name":"coord","prefix":"loc"}]}.
Then,wecanaddtheattrib-utetothephotobysendingaPUTrequesttothelocationofthephoto(e.
g.
/users/mary/photos/169/loc/coord)withthefollowingbody:{"attr":{"value":"45.
210.
7"}}.
5PreliminaryEvaluation5.
1PrototypeImplementationWehaveprototypedareferenceimplementationofthephotoservicethatwaspre-sentedintheprevioussection.
TheimplementationisbasedontheRubyonRails448C.
RivaandM.
Laitkorpiframework[4]thatprovidesseveralconvenientfeaturesfortheimplementationofRESTservices.
ToevaluatethebenefitsandthelimitationsoftheRESTdesignwehavetestedthebackedwiththethreedifferentclients:Maemo.
Itisthelinux-basedplatformfortheNokiainternettables770andN800.
WeimplementedtheclientusingthePythonscriptinglanguage.
JavaMIDP.
TheJavaMIDPenvironmentrunsonmostmobiledevices.
JavaMIDPsupportstheHTTPprotocolbutnotalltheHTTPactions(onlyGETandPOSTaresupported).
WehaveimplementedasimpleworkaroundforemulatingthePUTandDELETEoperationswithPOST.
WetestedtheclientonaNokiaN73device.
PythonforS60.
S60isNokia'splatformforsmartphonesandmultimediacom-puters.
WehaveimplementedtheclientusingtheportofthePythonlanguageonS60.
TheportprovidesfullsupportforthestandardHTTPlibmodule.
Mash-ups.
WehaveassembledourphotoservicewiththeservicesfromotherInternetsites(e.
g.
Googlemaps)withinthebrowserenvironment.
Themash-upshavebeenimplementedinJavascript.
5.
2MainObservationsOurgeneralevaluationofRESTformobileservicesispositivebuttherearestillsev-erallimitationsthatneedtobesolved.
Welistthemainpointsofourevaluationbelow:RESTwithHTTPprovidesauniformmechanismforbuildingwebservicesthatrequiresaminimalinfrastructureontheclientandtheserversides.
Mostimpor-tantly,thisapproachisindependentoftherun-timeenvironment,aslongasthereisdecentsupportforHTTPasacommondenominator.
Unfortunately,somerun-timelibrariestargetingmobiledevicesstilltreatHTTPasasimpletransportmechanisminsteadofaproperapplicationprotocol.
Forexample,MIMEmulti-partsupportistypicallyprovidedbythemaillibraries,anditsAPIisoftenin-compatiblewithHTTPmessageprocessingAPI,thusrenderingHTTPmultipartmessageparsingratherclumsyandinefficient.
Thenetworklatencyisaconcreteproblemforwebservices,especiallyfortheoveralluserexperienceontheclient-side.
Theuserinterfacerequiresaproperde-signtotakeintoconsiderationthelongroundtripperiodsfortransferringthedataacrossthewirelessnetwork.
Wehaveexperimentedwithtwosolutionsthatcanbeusedforbothreadandwriterequests.
Thefirstoneistoinlineadditionaldatainonerequest(e.
g.
inliningthethumbnails)thatallowsfetchingorupdating.
However,thissolutioninhibitstheindividualHTTPcachingoftheinlinedre-sources.
ThesecondoneistocreateconvenientURIsthatprovidemoreapplica-tion-specificdataeitherbybypassingoraugmentingthecoreAPI,effectivelycreatingcustomviewsontopoftheunderlyingcoreresources.
WhenproperlydesignedintermsofresourcesandtheirURIs,theseviewscanthenbeusedforbatchupdateswithasinglerequest,forexample.
However,thisapproachcompli-catesthedesignoftheback-end,becauseitmayintroducepotentiallycomplexapplication-specificaspectsontheserverside.
DesigningWeb-BasedMobileServiceswithREST449TheJSONdataformatsuitsverywellthemobileenvironment.
Itissimpletogenerate,toparse,andcompacttotransfer.
Accordingtoourpreliminarymeas-urements,however,thesizeofthetransferreddataisnotsignificantlysmallerthanthatofXMLdata,especiallywhenretainingthefieldnamesforself-descriptiveness.
WehavealsoextendedtheJSONformatwithbinarydatatosupporttheresponseinlining,becauseatthemomentwehavefoundthemultipartmessagestoocomplextobeprocessedontheclientside.
DesigningsimpleandintuitiveURIsisacriticalpartoftheRESTdesign.
Wehavesketchedasimpledata-orienteddesignprocessbutweneedamethodforspecifyingtheresourceswithaproperformalism.
EspeciallydeveloperswithoutpriorexperienceofRESTwouldgreatlybenefitfrommethodandtoolsupportthathelpthemmaptheirrequirementstoRESTfulresourcedesign.
Thereisalsotheopenissueofenablingthecomponent-likereuseofresourcesubtreesacrossdifferentpartsoftheAPI(e.
g.
reusingtheTagresourcebetweenthePhotoandVideoresource).
Inoursolution,wedonothaveanyexplicitsupportforofflineprocessing.
OurRESTfulapproach,however,inherentlyfitsmanyofflinescenarios,mainlybe-causeofstatelessness.
Forexample,idempotentrequestscanbequeuedontheclientsidequiteeasilyforlaterdelivery,butthisrequiresthatdynamicallycre-atedresourcesshouldhaveclient-providedURIs.
5.
3"MobileREST"Asexplainedabove,theroundtripcostisprobablythemostsignificantindividualchallengeinnetwork-basedmobileapplications.
Therefore,applyingRESTeffi-cientlyinmobileapplicationarchitecturesmayrequiresomeadditionalconstraintsthatguidethearchitectstomakemoremobile-friendlydecisions.
Theseconstraintswouldprimarilyneedtotacklethedilemmaof"justenoughrequests,justenoughdata".
Inverysimpleterms,"justenoughrequests"referstomechanismsthatgiveclientsenoughcontroltoadjustthescopeoftheRESTfulinteractions,thusreducingtheneedformultiplerequests.
Asanoppositedrivingforce,"justenoughdata"referstomechanismsthatclientsmayusetoadjustthevolumeofdatainasinglemessage.
Elaboratingtheseadditionalconstraintswillbepartofourfuturework.
6ConclusionsThegrowthandsuccessoftheWebmainlyderivefromathoroughapplicationofbasicdesignprinciplesthatarecrystallizedintheRESTstyle.
RESTisalsobecomingapopularparadigmforpublishingWebservices(asanalternativetotheWS-*stack).
InthecurrentpaperwehaveinvestigatedhowtoapplytheRESTprinciplestothedesignofmobileservices.
Wehaveidentifiedseveralissues(likenetworklatencyanddataformats)thatneedparticularattentionwhenapplyingtheRESTconceptstothemobileenvironment.
Fordemonstrationpurposes,wehaveprototypedaRESTphotowebserviceandtesteditwithdifferentmobileclients.
OurpreliminaryevaluationshowsthatRESTwithHTTPprovidesauniformmechanismforbuildingwebser-vicesthatrequiresaminimalinfrastructureontheclient-sideandisindependentof450C.
RivaandM.
Laitkorpitherun-timeenvironment.
Theserviceisextensiblewithdifferentdatarepresentationsand,hence,allowsustoproperlyaddressthemobilespecificneeds.
ThecriticalpartofthedesignprocessistoelaborateaclearURIstructurefortheAPI,allowingmo-bileclientstomakejustenoughrequestsandprocessjustenoughdata.
Wehavefol-lowedadata-drivendesignprocessbutwehavebeenlackingameticulousdesignformalism(e.
g.
,aUMLbasedapproachthathelpsdevelopersmaptheirrequirementstoRESTconstraints).
Ourfutureworkwillbefocusedonimprovingthedesignproc-essofRESTservices,especiallyforthemobileenvironment,andconductamorethoroughevaluationwithadditionalprototypes.
References1.
Fielding,R.
T.
:Architecturalstylesandthedesignofnetwork-basedsoftwarearchitectures,PhDThesis,UniversityofCalifornia,Irvine(2000)2.
Fielding,R.
T.
,Gettys,J.
,Mogul,J.
,Frystyk,H.
,Masinter,L.
,Leach,P.
,Berners-Lee,T.
:HypertextTransferProtocol–HTTP/1.
1.
InternetRFC2616(June1999)3.
Berners-Lee,T.
,Fielding,R.
T.
,Masinter,L.
:UniformResourceIdentifiers(URI):Genericsyntax.
InternetRFC2396(August1998)4.
Thomas,D.
,Hansson,D.
H.
:AgileWebDevelopmentwithRails,PragmaticBookshelf,2ndedn.
(December14,2006)5.
vanGurp,J.
,Karhinen,A.
,Bosch,J.
:MobileServiceOrientedArchitectures.
In:Eliassen,F.
,Montresor,A.
(eds.
)DAIS2006.
LNCS,vol.
4025,pp.
1–15.
Springer,Heidelberg(2006)6.
Freed,N.
,Borenstein,N.
:MultipurposeInternetMailExtensions.
InternetRFC2046(No-vember1996)7.
Nottingham,M.
,Sayre,R.
:TheAtomSyndicationFormat.
InternetRFC4287(December2005)8.
Greogiro,J.
,dehOra,B.
:TheAtomPublishingProtocol,InternetDraftversion17(No-vember2007)9.
Crockford,D.
:Theapplication/jsonMediaTypeforJavaScriptObjectNotation(JSON),InternetRFC4627(July2006)10.
WebServicesArchitecture,W3CWorkingGroupNote(February11,2004),http://www.
w3.
org/TR/ws-arch/11.
SOAP,Version1.
2,W3CRecommendation(Secondedn.
)(April27,2007),http://www.
w3.
org/TR/soap/