---
eip: 5219
title: Contract Resource Requests
description: Allows the requesting of resources from contracts
author: Gavin John (@Pandapip1)
discussions-to: https://ethereum-magicians.org/t/pr-5219-discussion-contract-rest/9907
status: Final
type: Standards Track
category: ERC
created: 2022-07-10
---

## Abstract

This EIP standardizes an interface 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).

### Note to Implementers

To save gas costs, it is recommended to use the `message/external-body` MIME-type, which allows you to point to data that the smart contract might not have access to. For example, the following response would tell a client to fetch the data off of IPFS:

```yaml
statusCode: 200
body: THIS IS NOT REALLY THE BODY!
headers:
  - key: Content-type
    value: message/external-body; access-type=URL; URL="ipfs://11148a173fd3e32c0fa78b90fe42d305f202244e2739"
```

## 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 bad user experience.
- Complicated front-end logic should not be stored in the smart contract, as it would be costly to deploy and would be better run 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

The normal security considerations of accessing normal URLs apply here, such as potential privacy leakage by following `3XX` redirects.

## Copyright

Copyright and related rights waived via [CC0](../LICENSE.md).