FRINK Linked Data Fragments server

Matches in SemOpenAlex for { <https://semopenalex.org/work/W2397876925> ?p ?o ?g. }

• W2397876925 endingPage "198" @default.
• W2397876925 startingPage "181" @default.
• W2397876925 abstract "We present an approach to write web applications in the programming languages Haskell [8] and Curry [6]. The web applications we propose are directly based on the Hypertext Transfer Protocol (HTTP) – no additional protocol on top of HTTP is necessary. Although the main ideas are not new and already applied using other programming languages, we believe that features present in modern declarative languages – especially algebraic datatypes – serve well to represent resources on the web. 1 TRANSFER OF RESOURCE REPRESENTATIONS A resource is any piece of information named by a Uniform Resource Identifier (URI). A web application provides access to internally stored information over the Internet or accesses such information provided by other web applications. Usually, (a representation of) this information is transferred using the Hypertext Transfer Protocol (HTTP) [3] – possibly employing some protocol on top of it. Note that we do not primarily consider applications running inside a web browser like [4, 7, 9]. HTTP provides different methods to access resources from which the most important are the GET and the POST method. GET is used to retrieve some information, e.g., web browsers use GET to ask for the content of web pages. POST is used to send information to be processed by a server, e.g., entries in a web form can be sent to the server using POST. While processing the request, the server can update its internally stored information and usually sends back a result of this process. Web applications differ in their use of these two HTTP methods: RPC-style web applications are accessible through a single URI and communication is performed using the POST method. A representation of a procedure call is transferred to the server, which returns a representation of the result of this call as answer to the POST request. Note that both retrieval and update operations are performed using the POST method in RPC-style web applications and the interface of such applications is determined by the procedure calls that are understood by the server. Fielding [2] proposes another architectural style for web applications: He proposes to use the POST method only to update the internal state of the server and to use the GET method to purely retrieve information. Consequently, everything that should be available for retrieval by clients needs to be identified by an own URI. This is a big difference to RPC-style web applications that are usually accessible ?This work was partially supported by the German Research Council (DFG) grant Ha 2457/5-1. through a single URI. In the architectural style proposed by Fielding, a client sends an HTTP GET request to an URI to retrieve a representation of the resource identified by this URI corresponding to the current state of the server. To change this state, the client sends a POST request to the URI of the resource he wants to update. Fielding calls this architectural style Representational State Transfer (REST). The interface of a RESTful web application is given by the methods of HTTP and the URIs identifying the applications resources. In this work, we show how the interface given by the most important HTTP methods can be made available to Haskell or Curry programmers, hiding the details of HTTP communication." @default.
• W2397876925 created "2016-06-24" @default.
• W2397876925 creator A5033061863 @default.
• W2397876925 date "2005-06-01" @default.
• W2397876925 modified "2023-09-23" @default.
• W2397876925 title "Resource-Based Web Applications" @default.
• W2397876925 cites W1508922656 @default.
• W2397876925 cites W2022137742 @default.
• W2397876925 cites W2025445894 @default.
• W2397876925 doi "https://doi.org/10.2307/j.ctv36xvknz.14" @default.
• W2397876925 hasPublicationYear "2005" @default.
• W2397876925 type Work @default.
• W2397876925 sameAs 2397876925 @default.
• W2397876925 citedByCount "0" @default.
• W2397876925 crossrefType "book-chapter" @default.
• W2397876925 hasAuthorship W2397876925A5033061863 @default.
• W2397876925 hasConcept C136764020 @default.
• W2397876925 hasConcept C206345919 @default.
• W2397876925 hasConcept C31258907 @default.
• W2397876925 hasConcept C41008148 @default.
• W2397876925 hasConceptScore W2397876925C136764020 @default.
• W2397876925 hasConceptScore W2397876925C206345919 @default.
• W2397876925 hasConceptScore W2397876925C31258907 @default.
• W2397876925 hasConceptScore W2397876925C41008148 @default.
• W2397876925 hasLocation W23978769251 @default.
• W2397876925 hasOpenAccess W2397876925 @default.
• W2397876925 hasPrimaryLocation W23978769251 @default.
• W2397876925 hasRelatedWork W1585501219 @default.
• W2397876925 hasRelatedWork W2087861504 @default.
• W2397876925 hasRelatedWork W2293168934 @default.
• W2397876925 hasRelatedWork W2351790455 @default.
• W2397876925 hasRelatedWork W2366882215 @default.
• W2397876925 hasRelatedWork W2570974996 @default.
• W2397876925 hasRelatedWork W2748952813 @default.
• W2397876925 hasRelatedWork W2752793062 @default.
• W2397876925 hasRelatedWork W2806254788 @default.
• W2397876925 hasRelatedWork W2947922949 @default.
• W2397876925 isParatext "false" @default.
• W2397876925 isRetracted "false" @default.
• W2397876925 magId "2397876925" @default.
• W2397876925 workType "book-chapter" @default.