PR-5219: Contract Resource Requests (ethereum#5219)

* Add eip-dhttp

* Self-assign EIP number

* I can't believe I somehow missed that

* Update EIPS/eip-5219.md

Co-authored-by: Micah Zoltu <micah@zoltu.net>

* Add actual solution to problem

* Formatting

* Update discussions-to link

* It worked locally though!

* Add extra newline

* Remove EIP-20 reference

* Add field that I missed

* Change the name to Contract REST & make a few more changes

* Move text from abstract to motivation

* Make suggested changes

* Remove EIP-165

* Alternative mechanism described

* Get rid of all EIP references

* Extremely slim down the spec

* Make the EIP motivation a bit more clearer throughout

* Change name to "Contract Resource Requests"

* Fix typos

Co-authored-by: Micah Zoltu <micah@zoltu.net>

EIPS/eip-5219.md

@@ -0,0 +1,66 @@
+---
+eip: 5219
+title: Contract Resource Requests
+description: Allows the requesting of resources from contracts
+author: Pandapip1 (@Pandapip1)
+discussions-to: https://ethereum-magicians.org/t/pr-5219-discussion-contract-rest/9907
+status: Draft
+type: Standards Track
+category: ERC
+created: 2022-07-10
+---
+
+## Abstract
+
+This EIP introduces an interface allowing clients to make resource requests to smart contracts, and to receive HTTP-like responses.
+
+## Motivation
+
+Ethereum is the most-established blockchain for building decentralized applications (referred to as `DApp`s). Due to this, the Ethereum DApp ecosystem is very diverse. However, one issue that plagues DApps is the fact that they are not fully decentralized. Specifically, to interface a "decentralized" application, one first needs to access a *centralized* website containing the DApp's front-end code, presenting a few issues. The following are some risks associated with using centralized websites to interface with decentralized applications:
+
+- Trust Minimization: An unnecessarily large number of entities need to be trusted
+- Censorship: A centralized website is not resistant to being censored
+- Permanence: The interface may not have a mechanism that permits it to be permanently stored
+- Interoperability: Smart Contracts cannot directly interact with DApp interfaces
+
+## Specification
+
+The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.
+
+### Name Resolution
+
+EIPs that propose a name resolution mechanism MAY reference this EIP and MAY recommend that clients support their mechanism. Clients MAY also support regular DNS, as defined in RFC 1034 and RFC 1035.
+
+### Separation of Concerns
+
+It is RECOMMENDED to separate the application logic from the front-end logic (the contract implementing the interface defined in [Contract Interface](#contract-interface)).
+
+### Contract Interface
+
+DApp contracts MUST implement the interface defined in the following file: [Contract Interface](../assets/eip-5219/IDecentralizedApp.sol).
+
+## Rationale
+
+The `request` method was chosen to be readonly because all data should be sent to the contract from the parsed DApp. Here are some reasons why:
+
+- Submitting a transaction to send a request would be costly and would require waiting for the transaction to be mined, resulting in quite possibly the worst user-experience possible.
+- Complicated front-end logic should not be stored in the smart contract, as it would be costly to deploy and would be better ran on the end-user's machine.
+- Separation of Concerns: the front-end contract shouldn't have to worry about interacting with the back-end smart contract.
+- Other EIPs can be used to request state changing operations in conjunction with a `307 Temporary Redirect` status code.
+
+Instead of mimicking a full HTTP request, a highly slimmed version was chosen for the following reasons:
+- The only particularly relevant HTTP method is `GET`
+- Query parameters can be encoded in the resource.
+- Request headers are, for the most part, unnecessary for `GET` requests.
+
+## Backwards Compatibility
+
+This EIP is backwards compatible with all standards listed in the [Name Resolution](#name-resolution) section.
+
+## Security Considerations
+
+Needs discussion.
+
+## Copyright
+
+Copyright and related rights waived via [CC0](../LICENSE.md).

assets/eip-5219/IDecentralizedApp.sol

@@ -0,0 +1,16 @@
+// SPDX-License-Identifier: CC0-1.0
+pragma solidity ^0.8.0;
+
+struct KeyValue {
+    string key;
+    string value;
+}
+
+interface IDecentralizedApp {
+    /// @notice                     Send an HTTP GET-like request to this contract
+    /// @param  resource            The resource to request (e.g. "/asdf/1234" turns in to ["asdf", "1234"])
+    /// @return statusCode          The HTTP status code (e.g. 200)
+    /// @return body                The body of the response
+    /// @return headers             A list of header names (e.g. [{ key: "Content-Type", value: "application/json" }])
+    function request(string[] memory resource) external view returns (uint8 statusCode, string memory body, KeyValue[] headers);
+}