No full-text available
To read the full-text of this research,
you can request a copy directly from the authors.
RESTful Web Services – A Question of Standards
Abstract
Roy Thomas Fielding defined the term REST as an architectural style for distributed hypermedia based systems in the year 2000. Since this initial definition, the term itself became a buzzword used in almost any web-related develop- ment. From simple, basic web applications, to highly complex web service/microservice-based solutions, almost everyone and everything talks REST and RESTful. Moreover, the Web context implies that these developments are usually realised over HTTP. In this paper, we first analyse the impact of this architectural style on distributed application development. A careless application of this model and its underlying HTTP standards could severely impact on the overall quality of any RESTful based solution. Following, we submit our own model for user data and session handling tasks to illustrate the correct approach to RESTful web service design techniques. This model offers all the advantages of the aforementioned architectural style while providing the required functionality for the authentication and authorisation components of all web based applications.
Index Terms—REST, Resource-Oriented-Architecture, Web Services, Service-Oriented-Architecture, Distributed Systems Ar- chitecture/Design
... RESTful Web APIs are based on the principles of REST architecture, which defines a set of architectural constraints that a web service must adhere to be considered RESTful, first described by Roy Fielding in his doctoral dissertation [2]. A RESTful Web API must follow these six architectural constraints [20]: ...
Application Programming Interfaces (APIs) are available in virtually every programming language. These interfaces make it easier to develop software by simplifying complex code into a more straightforward, manageable structure. APIs provide a standardized interface that allows different applications to communicate and connect easily, streamlining the software development process and making it more efficient and effective. Performance testing of a web API refers to evaluating the performance characteristics of an API accessible via the web. This process involves analyzing performance aspects such as response time, reliability, scalability, and resource utilization. This work defines a test battery using specific open-source tools to assess Web API performance. The tests used are load, stress, spike, and soak tests replicating various scenarios of the volume of users accessing the service or simulating a denial-of-service attack. These tests aim to determine how well an API can manage a substantial volume of traffic and transactions while upholding satisfactory performance standards. Applying Web API performance testing will also enable organizations to implement suitable measures for enhancing performance and guaranteeing smooth user interaction, pinpointing bottlenecks, constraints, or prospective problems in the API’s architecture and execution. These tests can also demonstrate the technology’s limitations and benchmarking, helping determine a more suitable production platform.
... Resource representations are used by authorized clients, and the states of these resources describe possible/admissible actions to the client. The resource is the core element of the REST architectural style and can have one or more valid formats that are described using the metadata [12]. ...
The widespread adoption of Cloud-Based Web Microservices (CBWMs) and DevSecOps (Development, Security, and Operations) methodologies has significantly improved modern software development, particularly regarding scalability, agility, and security. However, the true success of these implementations hinges on the ability to measure their effectiveness accurately. Metrics serve as a critical tool in this process, providing quantifiable data on service performance, security, and operational efficiency. By leveraging these metrics, organizations can better assess the efficiency of their DevSecOps practices, making them invaluable for informed decision-making, trend analysis, process management, and continuous improvement. This paper introduces 12 key quantitative metrics specifically designed to evaluate the quality of CBWMs developed through DevSecOps practices. These metrics were identified using a Multi-Vocal Literature Reviewmethodology, sourcing information from 92 relevant studies (2018-2023) on IEEE Xplore, Springer, and Google Scholar. The selected metrics are widely applicable across CBWMs and are easy to measure with existing tools, offering a comprehensive framework for thorough assessment.
In several branches of computer science, network monitoring tools are used to continuously monitor a network system's daily functioning, incoming and outgoing packet data, and whether the system is executing its job well. Diagnostic tools, on the other hand, are used to identify faults in a system. Existing tools are typically disjointed, ineffective and out of reach for the average user, and while some may produce verbose outputs, their decoupled nature, as well as the fact that the majority of them do not have a particularly appealing appearance, all accounts for a frustrating user experience. The necessity for a user-friendly interface and the extension of legacy tools necessitates the creation of a suite which this project aims to create that all types of end users can access and use an integrated monitoring and diagnostic suite easily.
In today's Web-centric era, embedded systems become mashup various web services via RESTful web services. RESTful web services use REST APIs that describe actions as resource state transfers via standard HTTP methods such as GET, PUT, POST, and DELETE. While RESTful web services are lightweight and executable on any platforms that support HTTP methods, writing programs composed of only such primitive methods is not a familiar concept to developers. Therefore, no single design strategy for (fully) RESTful APIs works for arbitrary domains, and current REST APIs are system dependent, incomplete, and likely to change. To help sever-side development of REST APIs, several domain-specific languages such as WADL, WSDL 2.0, and RDF provide automatic tools to generate REST APIs. However, client-side developers who often do not know the web services domain and do not understand RESTful web services suffer from the lack of any development help. In this paper, we present a new approach to build JavaScript APIs that are more accessible to client-side developers than REST APIs. We show a case study of our approach that uses JavaScript APIs and their wrapper implementation instead of REST APIs, and we describe the efficiency in the client-side development.
In this article a formal model applying REST architectural principles to the description of semantic web services is introduced, including the discussion of its syntax and operational semantics. RESTful semantic resources are described using the concept of tuple spaces being manipulated by HTTP methods that are related to classical tuple space operations. On the other hand, RESTful resources creation, destruction and other dynamic aspects of distributed HTTP computations involving coordination between HTTP agents and services are modeled using process calculus style named channels and message passing mechanisms. The resulting model allows for a complete and rigorous description of resource based web systems, where agents taking part in a computation publish data encoded according to semantic standards through public triple repositories identified by well known URIs. The model can be used to describe complex interaction scenarios where coordination and composition of resources are required. One of such scenarios taken from the literature about web services choreography is analyzed from the point of view of the proposed model. Finally, possible extensions to the formalism, such as the inclusion of a description logics based type system associated to the semantic resources or possible extensions to HTTP operations are briefly explored.
Service descriptions allow designers to document, understand, and use services, creating new useful and complex services with aggregated business value. Unlike RPC-based services, REST characteristics require a different approach to service description. We present the Resource Linking Language (ReLL) that introduces the concepts of media types, resource types, and link types as first class citizens for a service description. A proof of concept, a crawler called RESTler that crawls RESTful services based on ReLL descriptions, is also presented.
Recent technology trends in Web services indicate that a solution eliminating the perceived complexity of the WS-* standard technology stack may be in sight: advocates of Representational State Transfer (REST) have come to believe that their ideas explaining why the World Wide Web works are just as applicable to solve enterprise application integration problems and to radically simplify the plumbing required to implement a Service-Oriented Architecture (SOA). In this tutorial we give an introduction to the REST architectural style as the foundation for RESTful Web services. The tutorial starts from the basic design principles of REST and how they are applied to service oriented computing. Service-orientation concentrates on identifying self-contained units of functionality, which should then be exposed as easily reusable and repurposable services. This tutorial focuses not on the identification of those units, but on how to design the services representing them. We explain how decisions on the SOA level already shape the architectural style that will be used for the eventual IT architecture, and how the SOA process itself has to be controlled to yield services which can then be implemented RESTfully. We do not claim that REST is the only architectural style that can be used for SOA design, but we do argue that it does have distinct advantages for loosely coupled services and massive scale, and that any SOA approach already has to be specifically RESTful on the business level to yield meaningful input for IT architecture design.
Seventeen years after its initial publication at ICSE 2000, the Representational State Transfer (REST) architectural style continues to hold significance as both a guide for understanding how the World Wide Web is designed to work and an example of how principled design, through the application of architectural styles, can impact the development and understanding of large-scale software architecture. However, REST has also become an industry buzzword: frequently abused to suit a particular argument, confused with the general notion of using HTTP, and denigrated for not being more like a programming methodology or implementation framework.
In this paper, we chart the history, evolution, and shortcomings of REST, as well as several related architectural styles that it inspired, from the perspective of a chain of doctoral dissertations produced by the University of California's Institute for Software Research at UC Irvine. These successive theses share a common theme: extending the insights of REST to new domains and, in their own way, exploring the boundary of software engineering as it applies to decentralized software architectures and architectural design. We conclude with discussion of the circumstances, environment, and organizational characteristics that gave rise to this body of work.
Nowadays, the REST (Representational State Transfer) is becoming the most commonly used way how to create, publish, and consume Web Services, exploiting JSON (JavaScript Object Notation) as the data exchange format. However, there are still no official standards for REST (like WSDL for Web Services) and for JSON (like XML Schema for the XML language). Next, there are no defined instructions how the resource versions should be managed.
In this paper we focus on managing and generating REST resources based on the MDA (Model-Driven Architecture) principle which enables designing and maintenance of complex projects. We introduce a way how to describe the REST API in MDA and how to provide automatic evolution management between subsequent API versions derived from the original version. The proposed solution describes a novel model which represents REST requests and algorithms for providing evolution of this model based on changes done in the PIM (Platform-Independent Model) of MDA.
Starting with RESTful design is a difficult task -- even more if the designer has a RPC or object-oriented background. To support the adaption from RPC- to REST-oriented thinking, we propose RESTify, a straightforward procedure model to redesign a RPC-oriented interface into a hypermedia-enabled REST interface. RESTfiy uses a WSDL document of an existing SOAP service and consists of three iterations. The result of each iteration is an enhanced version of the preceding one concerning the REST constraints and is meant to be implemented as a HTTP service. Beside the technical result of the process and the design of a RESTful interface, the developer becomes acquainted to the main elements of a RESTful design, the constraints and their application. The results of the evaluation, using a prototypical web application and public SOAP services, are promising.
This article describes the Web Application Description Language (WADL). An increasing number of Web-based enterprises (Google, Yahoo, Amazon, Flickr - to name but a few) are developing HTTP-based applications that provide access to their internal data using XML. Typically these applications are described using a combination of textual protocol descriptions combined with XML schema-based data format descriptions; WADL is designed to provide a machine processable protocol description format for use with such HTTP-based Web applications, especially those using XML.
REpresentational State Transfer (REST) guided the creation and expansion of the modern web. What began as an internet-scale distributed hypermedia system is now a vast sea of shared and interdependent services. However, despite the expressive power of REST, not all of its benefits are consistently realized by working systems. To resolve the dissonance between the promise of REST and the reality of fielded systems, we critically examine numerous web architectures. Our investigation yields a set of extensions to REST, an architectural style called Computational REST (CREST), that not only offers additional design guidance, but pinpoints, in many cases, the root cause of the apparent dissonance between style and implementation. Furthermore, CREST explains emerging web architectures (such as mashups) and points to novel computational structures.
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.
A Uniform Resource Identifier (URI) is a compact string of characters for identifying an abstract or physical resource. This document defines the generic syntax of URI, including both absolute and relative forms, and guidelines for their use; it revises and replaces the generic definitions in RFC 1738 and RFC 1808.
Reflections on the REST Architectural Style and
- R T Fielding
- R N Taylor
- J R Erenkrantz
- M M Gorlick
- J Whitehead
- R Khare
- P Oreizy
Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing
- R T Fielding
- J Reschke
R. T. Fielding and J. Reschke. (2014, June) Hypertext Transfer Protocol
(HTTP/1.1): Message Syntax and Routing. [Online]. Available:
https://tools.ietf.org/html/rfc7230
HyperText Transfer Protocol (HTTP/1.1): Semantics and content
- R T Fielding
- J Reschke
R. T. Fielding and J. Reschke. (2014, June) HyperText Transfer
Protocol (HTTP/1.1): Semantics and content. [Online]. Available:
https://tools.ietf.org/html/rfc7231
PATCH Method for HTTP
- L Dusseault
- J Snell
February) Web services architecture
- D Booth
- H Haas
- F Mccabe
- E Newcomer
- M Champion
- C Ferris
- D Orchard
D. Booth, H. Haas, F. McCabe, E. Newcomer, M. Champion, C. Ferris,
and D. Orchard. (2004, February) Web services architecture. [Online].
Available: https://www.w3.org/TR/ws-arch/
March) PATCH Method for HTTP
- L Dusseault
- J Snell
L. Dusseault and J. Snell. (2010, March) PATCH Method for HTTP.
[Online]. Available: https://tools.ietf.org/html/rfc5789
Reflections on the REST Architectural Style and
- fielding