For the last several decades the predominant architectural style for the implementation of data-centric applications has had a relational database at the core, procedural code implementing the application services and an object-oriented API. More recently the API has transitioned, via a slight detour through SOAP-based web services, to a RESTful style, however what lies beneath that interface has been slower to take a new approach. In this paper we argue that upgrading that which is under the covers to an XML-centric technology stack will result in a system that is easier to build, test and maintain. Further, these technologies are a step toward making construction of such systems available to non-programmers. We present an XML RESTful Services framework that provides mechanisms to address all of the key aspects of systems built in the RESTful architectural style.
{"title":"XML technologies for RESTful services development","authors":"C. Davis, Tom Maguire","doi":"10.1145/1967428.1967437","DOIUrl":"https://doi.org/10.1145/1967428.1967437","url":null,"abstract":"For the last several decades the predominant architectural style for the implementation of data-centric applications has had a relational database at the core, procedural code implementing the application services and an object-oriented API. More recently the API has transitioned, via a slight detour through SOAP-based web services, to a RESTful style, however what lies beneath that interface has been slower to take a new approach. In this paper we argue that upgrading that which is under the covers to an XML-centric technology stack will result in a system that is easier to build, test and maintain. Further, these technologies are a step toward making construction of such systems available to non-programmers. We present an XML RESTful Services framework that provides mechanisms to address all of the key aspects of systems built in the RESTful architectural style.","PeriodicalId":268294,"journal":{"name":"International Workshop on RESTful Design","volume":"60 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2011-03-28","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"126458098","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
One of the main REST design principles is the focus on media types as the core of contracts on the Web. However, not always is the service designer free to select the most appropriate media type for a task, sometimes a generic media type like application/rdf+xml (or in the worst case a binary format like image/png) with no defined or possible hypermedia controls at all has to be chosen. With this position paper we present a way how the hypermedia constraint of REST can still be fulfilled using a combination of Link headers, the OPTIONS method, and the HTTP Vocabulary in RDF.
{"title":"Fulfilling the hypermedia constraint via HTTP OPTIONS, the HTTP vocabulary in RDF, and link headers","authors":"T. Steiner, Jan Algermissen","doi":"10.1145/1967428.1967433","DOIUrl":"https://doi.org/10.1145/1967428.1967433","url":null,"abstract":"One of the main REST design principles is the focus on media types as the core of contracts on the Web. However, not always is the service designer free to select the most appropriate media type for a task, sometimes a generic media type like application/rdf+xml (or in the worst case a binary format like image/png) with no defined or possible hypermedia controls at all has to be chosen. With this position paper we present a way how the hypermedia constraint of REST can still be fulfilled using a combination of Link headers, the OPTIONS method, and the HTTP Vocabulary in RDF.","PeriodicalId":268294,"journal":{"name":"International Workshop on RESTful Design","volume":"2 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2011-03-28","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"131539758","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
Michael Athanasopoulos, K. Kontogiannis, C. Brealey
Interface uniformity is regarded as one of the most distinctive features of the REST architectural style among other network-based styles, because of the specific set of restrictions it imposes on the behavior paradigms of interacting components. However, in practice conforming to the REST's uniform interface constraint in Web-based services most often proves to be a difficult task, as identified by a number of researchers and practitioners. This implementation and conformance difficulty can be partly attributed to the lack of a systematic conceptual framework that could be used to interpret abstract architectural restrictions of interface uniformity to practical design decisions and strategies being generalized as interface design criteria. These criteria could be then mapped to domain-specific techniques that provide the context for guiding and/or examining the level of uniformity of a REST-based API. In this paper, we discuss such a conceptual framework and a collection of criteria that can be used to assess in a practical way as to whether a specific REST-based API conforms to the uniform interface constraint. As a proof of concept, we evaluated the proposed framework and its associated methodology by applying it to a collection of indicative public Web service APIs.
{"title":"Towards an interpretation framework for assessing interface uniformity in REST","authors":"Michael Athanasopoulos, K. Kontogiannis, C. Brealey","doi":"10.1145/1967428.1967440","DOIUrl":"https://doi.org/10.1145/1967428.1967440","url":null,"abstract":"Interface uniformity is regarded as one of the most distinctive features of the REST architectural style among other network-based styles, because of the specific set of restrictions it imposes on the behavior paradigms of interacting components. However, in practice conforming to the REST's uniform interface constraint in Web-based services most often proves to be a difficult task, as identified by a number of researchers and practitioners. This implementation and conformance difficulty can be partly attributed to the lack of a systematic conceptual framework that could be used to interpret abstract architectural restrictions of interface uniformity to practical design decisions and strategies being generalized as interface design criteria. These criteria could be then mapped to domain-specific techniques that provide the context for guiding and/or examining the level of uniformity of a REST-based API. In this paper, we discuss such a conceptual framework and a collection of criteria that can be used to assess in a practical way as to whether a specific REST-based API conforms to the uniform interface constraint. As a proof of concept, we evaluated the proposed framework and its associated methodology by applying it to a collection of indicative public Web service APIs.","PeriodicalId":268294,"journal":{"name":"International Workshop on RESTful Design","volume":"8 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2011-03-28","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"116071872","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
The Ideate Framework is the result of a property-driven software development effort intended to improve the effectiveness and efficiency of Knowledge-work. The keys to supporting such work are identified as context-awareness and mass-customization, both of which are provided for by the framework in a practical, lightweight, scalable, and adaptable manner. Underpinning the framework is a new hybrid architecture promoting the scalability of distributed enterprise systems and the delivery of server-driven applications. The architecture shares some similarity to the Representational State Transfer (REST) style, against which it is contrasted. In addition, this paper describes the key components of the Ideate Framework, and compares the results against other related approaches.
理想框架是属性驱动软件开发工作的结果，旨在提高知识工作的有效性和效率。支持这类工作的关键是上下文感知和大规模定制，框架以实用、轻量级、可扩展和可适应的方式提供了这两者。支撑该框架的是一个新的混合体系结构，它促进了分布式企业系统的可伸缩性和服务器驱动应用程序的交付。该体系结构与具象状态传输(Representational State Transfer, REST)风格有一些相似之处，并与之形成对比。此外，本文描述了理想框架的关键组成部分，并将结果与其他相关方法进行了比较。
{"title":"A resource oriented framework for context-aware enterprise applications","authors":"D. Duggal, W. Malyk","doi":"10.1145/1967428.1967438","DOIUrl":"https://doi.org/10.1145/1967428.1967438","url":null,"abstract":"The Ideate Framework is the result of a property-driven software development effort intended to improve the effectiveness and efficiency of Knowledge-work. The keys to supporting such work are identified as context-awareness and mass-customization, both of which are provided for by the framework in a practical, lightweight, scalable, and adaptable manner. Underpinning the framework is a new hybrid architecture promoting the scalability of distributed enterprise systems and the delivery of server-driven applications. The architecture shares some similarity to the Representational State Transfer (REST) style, against which it is contrasted. In addition, this paper describes the key components of the Ideate Framework, and compares the results against other related approaches.","PeriodicalId":268294,"journal":{"name":"International Workshop on RESTful Design","volume":"142 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2011-03-28","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"134137339","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
Hypermedia as the Engine of Application State, or HATEOAS, is one of the constraints of the REST architectural style. It requires service responses to link to the next valid application states. This frees clients from having to know about all the service's URLs and the details of its domain application protocol. Few services support HATEOAS, though. In most cases, client programmers need to duplicate business logic and URL schemas already present in the service. These dependencies result in clients that are more likely to break when changes occur. But existing services cannot be easily updated to support HATEOAS: Clients could cease working correctly when a service is changed. Also, client developers might not have access to the service's source code, be it for technical or political reasons. We discuss which information is needed to create a HATEOAS-compliant wrapper service for an existing service. We include a notation for modeling possible application states and transitions based on UML State Charts. We demonstrate the feasibility and advantages of our approach by comparing the clients for an existing service and its wrapped counterpart. Our approach enables client developers to wrap third-party services behind an HATEOAS-compliant layer. This moves the tight coupling away from potentially many clients to a single wrapper service that may easily be regenerated when the original service changes.
{"title":"Teaching old services new tricks: adding HATEOAS support as an afterthought","authors":"Olga Liskin, Leif Singer, K. Schneider","doi":"10.1145/1967428.1967432","DOIUrl":"https://doi.org/10.1145/1967428.1967432","url":null,"abstract":"Hypermedia as the Engine of Application State, or HATEOAS, is one of the constraints of the REST architectural style. It requires service responses to link to the next valid application states. This frees clients from having to know about all the service's URLs and the details of its domain application protocol.\u0000 Few services support HATEOAS, though. In most cases, client programmers need to duplicate business logic and URL schemas already present in the service. These dependencies result in clients that are more likely to break when changes occur. But existing services cannot be easily updated to support HATEOAS: Clients could cease working correctly when a service is changed. Also, client developers might not have access to the service's source code, be it for technical or political reasons.\u0000 We discuss which information is needed to create a HATEOAS-compliant wrapper service for an existing service. We include a notation for modeling possible application states and transitions based on UML State Charts. We demonstrate the feasibility and advantages of our approach by comparing the clients for an existing service and its wrapped counterpart. Our approach enables client developers to wrap third-party services behind an HATEOAS-compliant layer. This moves the tight coupling away from potentially many clients to a single wrapper service that may easily be regenerated when the original service changes.","PeriodicalId":268294,"journal":{"name":"International Workshop on RESTful Design","volume":"3 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2011-03-28","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"131968008","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
Today, Representational State Transfer (REST) is becoming more and more important. RESTful web services are an alternative to Remote Procedure Call technologies like SOAP and WS-* services. There are many frameworks for implementing RESTful applications, but there is still a lack of support for the early phases of the development process, particularly analysis and design. For building formal models of RESTful applications an appropriate metamodel is needed. After analyzing existing approaches and techniques a first version of such a REST metamodel is presented and used to model an example application. Beside enabling modeling, such a metamodel offers a vocabulary for REST in practice and the basis for model driven development.
如今，具象状态转移(Representational State Transfer, REST)变得越来越重要。RESTful web服务是远程过程调用技术(如SOAP和WS-*服务)的替代方案。实现RESTful应用程序的框架有很多，但是仍然缺乏对开发过程早期阶段的支持，特别是分析和设计。为了构建RESTful应用程序的正式模型，需要一个适当的元模型。在分析了现有的方法和技术之后，提出了这种REST元模型的第一个版本，并将其用于为示例应用程序建模。除了支持建模之外，这种元模型还为实践中的REST提供了词汇表和模型驱动开发的基础。
{"title":"Modeling RESTful applications","authors":"Silvia Schreier","doi":"10.1145/1967428.1967434","DOIUrl":"https://doi.org/10.1145/1967428.1967434","url":null,"abstract":"Today, Representational State Transfer (REST) is becoming more and more important. RESTful web services are an alternative to Remote Procedure Call technologies like SOAP and WS-* services. There are many frameworks for implementing RESTful applications, but there is still a lack of support for the early phases of the development process, particularly analysis and design. For building formal models of RESTful applications an appropriate metamodel is needed. After analyzing existing approaches and techniques a first version of such a REST metamodel is presented and used to model an example application. Beside enabling modeling, such a metamodel offers a vocabulary for REST in practice and the basis for model driven development.","PeriodicalId":268294,"journal":{"name":"International Workshop on RESTful Design","volume":"17 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2011-03-28","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"127094281","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
We have designed and implemented RestFS, a software framework that provides a uniform, configurable connector layer for mapping remote web-based resources to local filesystem-based resources, recognizing the similarity between these two types of resources. Such mappings enable programmatic access to a resource, as well as composition of two or more resources, through the local operating system's standard filesystem application programming interface (API), scriptable file-based command-line utilities, and inter-process communication (IPC) mechanisms. The framework supports automatic and manual authentication. We include several examples intended to show the utility and practicality of our framework.
{"title":"RestFS: resources and services are filesystems, too","authors":"J. Kaylor, Konstantin Läufer, G. Thiruvathukal","doi":"10.1145/1967428.1967439","DOIUrl":"https://doi.org/10.1145/1967428.1967439","url":null,"abstract":"We have designed and implemented RestFS, a software framework that provides a uniform, configurable connector layer for mapping remote web-based resources to local filesystem-based resources, recognizing the similarity between these two types of resources. Such mappings enable programmatic access to a resource, as well as composition of two or more resources, through the local operating system's standard filesystem application programming interface (API), scriptable file-based command-line utilities, and inter-process communication (IPC) mechanisms. The framework supports automatic and manual authentication. We include several examples intended to show the utility and practicality of our framework.","PeriodicalId":268294,"journal":{"name":"International Workshop on RESTful Design","volume":"98 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2011-03-28","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"126897510","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
An Obligation is an expression of non-functional or cross-cutting requirements, the scope of which transcends any specific service, but for which the service bears an enforcement responsibility. Example use cases include regulations imposed on handling of Electronic Health Records. We describe the concept of an Obligation, provide example use cases, and then define a general design pattern for when a REST developer should consider their use. We then describe a proof-of-concept implementation that extends the Spring Security framework to support the assertion of Obligations within a RESTful service deployment. This extension may be used to inject a range of Obligation behaviors into a REST service during the design, deployment, and post deployment phases. Our prototype is compatible with the XACML 3.0 core standard.
{"title":"A framework for obligation fulfillment in REST services","authors":"John P. Field, Stephen Graham, Tom Maguire","doi":"10.1145/1967428.1967443","DOIUrl":"https://doi.org/10.1145/1967428.1967443","url":null,"abstract":"An Obligation is an expression of non-functional or cross-cutting requirements, the scope of which transcends any specific service, but for which the service bears an enforcement responsibility. Example use cases include regulations imposed on handling of Electronic Health Records. We describe the concept of an Obligation, provide example use cases, and then define a general design pattern for when a REST developer should consider their use. We then describe a proof-of-concept implementation that extends the Spring Security framework to support the assertion of Obligations within a RESTful service deployment. This extension may be used to inject a range of Obligation behaviors into a REST service during the design, deployment, and post deployment phases. Our prototype is compatible with the XACML 3.0 core standard.","PeriodicalId":268294,"journal":{"name":"International Workshop on RESTful Design","volume":"67 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2011-03-28","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"131338472","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
At a first glance there might appear to be an obvious alignment and overlap between the approaches prescribed by REST and Linked Data. On more detailed inspection divergences in scope and applicability present themselves, and for some aspects, incompatibility. In this paper we investigate these similarities and differences and suggest the coupling is worthy of a third look: in combination as a flexible environment in which the developer can focus on domain driven applications.
{"title":"REST and Linked Data: a match made for domain driven development?","authors":"Kevin R. Page, D. D. Roure, K. Martinez","doi":"10.1145/1967428.1967435","DOIUrl":"https://doi.org/10.1145/1967428.1967435","url":null,"abstract":"At a first glance there might appear to be an obvious alignment and overlap between the approaches prescribed by REST and Linked Data. On more detailed inspection divergences in scope and applicability present themselves, and for some aspects, incompatibility. In this paper we investigate these similarities and differences and suggest the coupling is worthy of a third look: in combination as a flexible environment in which the developer can focus on domain driven applications.","PeriodicalId":268294,"journal":{"name":"International Workshop on RESTful Design","volume":"27 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2011-03-28","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"133231460","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
We believe that there is a need for a practical model to visualize the structure and design rationale of REST, so researchers can study more easily the reutilization of this architectural style or parts of it, to the design of software solutions with different requirements than those of the early WWW. In this work we propose the utilization of extended influence diagrams to represent the structure and design rationale of an architectural style. The model is evaluated qualitatively by showing how a diagram of REST, populated with information extracted from the doctoral dissertation that introduced the term, is helpful to gain a better understanding of the properties and limitations of this style, and to reason about potential modifications for applications with different goals than those of the early WWW.
{"title":"Towards a practical model to facilitate reasoning about REST extensions and reuse","authors":"Federico Fernandez, Jaime C. Navón","doi":"10.1145/1798354.1798383","DOIUrl":"https://doi.org/10.1145/1798354.1798383","url":null,"abstract":"We believe that there is a need for a practical model to visualize the structure and design rationale of REST, so researchers can study more easily the reutilization of this architectural style or parts of it, to the design of software solutions with different requirements than those of the early WWW.\u0000 In this work we propose the utilization of extended influence diagrams to represent the structure and design rationale of an architectural style. The model is evaluated qualitatively by showing how a diagram of REST, populated with information extracted from the doctoral dissertation that introduced the term, is helpful to gain a better understanding of the properties and limitations of this style, and to reason about potential modifications for applications with different goals than those of the early WWW.","PeriodicalId":268294,"journal":{"name":"International Workshop on RESTful Design","volume":"15 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2010-04-26","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"131730329","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
京公网安备 11010802042870号
京ICP备2023020795号-1
扫码关注我们
求助内容：
应助结果提醒方式：