Using Web Platform APIs
Deno aims to use web platform APIs (like fetch
) instead of inventing a new
proprietary API where it makes sense. These APIs generally follow the
specifications and should match the implementation in Chrome and Firefox. In
some cases it makes sense to deviate from the spec slightly, because of the
different security model Deno has.
Here is a list of web platform APIs Deno implements:
- Blob
- BroadcastChannel
- Cache
- Channel Messaging API
- Compression Streams API
- Console
- DOM APIs
- DOM
CustomEvent
,EventTarget
andEventListener
- Encoding API
- Fetch API
FormData
- Location API
navigator.language
API- Performance API
setTimeout
,setInterval
,clearInterval
- Streams API
URL
URLPattern
URLSearchParams
- Web Crypto API
- Web File API
- Web Storage API
- Web Workers API
WebSocket
You can find the Deno reference for these APIs here.
fetch
API
Overview
The fetch
API can be used to make HTTP requests. It is implemented as
specified in the WHATWG fetch
spec.
You can find documentation about this API on MDN.
Spec deviations
- The Deno user agent does not have a cookie jar. As such, the
set-cookie
header on a response is not processed, or filtered from the visible response headers. - Deno does not follow the same-origin policy, because the Deno user agent
currently does not have the concept of origins, and it does not have a cookie
jar. This means Deno does not need to protect against leaking authenticated
data cross origin. Because of this Deno does not implement the following
sections of the WHATWG
fetch
specification:- Section
3.1. 'Origin' header
. - Section
3.2. CORS protocol
. - Section
3.5. CORB
. - Section
3.6. 'Cross-Origin-Resource-Policy' header
. Atomic HTTP redirect handling
.- The
opaqueredirect
response type.
- Section
- A
fetch
with aredirect
mode ofmanual
will return abasic
response rather than anopaqueredirect
response. - The specification is vague on how
file:
URLs are to be handled. Firefox is the only mainstream browser that implements fetchingfile:
URLs, and even then it doesn't work by default. As of Deno 1.16, Deno supports fetching local files. See the next section for details. - The
request
andresponse
header guards are implemented, but unlike browsers do not have any constraints on which header names are allowed. - The
referrer
,referrerPolicy
,mode
,credentials
,cache
,integrity
,keepalive
, andwindow
properties and their relevant behaviours inRequestInit
are not implemented. The relevant fields are not present on theRequest
object. - Request body upload streaming is supported (on HTTP/1.1 and HTTP/2). Unlike the current fetch proposal, the implementation supports duplex streaming.
- The
set-cookie
header is not concatenated when iterated over in theheaders
iterator. This behaviour is in the process of being specified.
Fetching local files
As of Deno 1.16, Deno supports fetching file:
URLs. This makes it easier to
write code that uses the same code path on a server as local, as well as easier
to author code that works both with the Deno CLI and Deno Deploy.
Deno only supports absolute file URLs, this means that fetch("./some.json")
will not work. It should be noted though that if
--location
is specified, relative URLs use the
--location
as the base, but a file:
URL cannot be passed as the
--location
.
To be able to fetch some resource, relative to the current module, which would
work if the module is local or remote, you would want to use import.meta.url
as the base. For example, something like:
const response = await fetch(new URL("./config.json", import.meta.url));
const config = await response.json();
Notes on fetching local files:
- Permissions are applied to reading resources, so an appropriate
--allow-read
permission is needed to be able to read a local file. - Fetching locally only supports the
GET
method, and will reject the promise with any other method. - A file that does not exist simply rejects the promise with a vague
TypeError
. This is to avoid the potential of fingerprinting attacks. - No headers are set on the response. Therefore it is up to the consumer to determine things like the content type or content length.
- Response bodies are streamed from the Rust side, so large files are available in chunks, and can be cancelled.
CustomEvent
, EventTarget
and EventListener
Overview
The DOM Event API can be used to dispatch and listen to events happening in an application. It is implemented as specified in the WHATWG DOM spec.
You can find documentation about this API on MDN.
Spec deviations
- Events do not bubble, because Deno does not have a DOM hierarchy, so there is no tree for Events to bubble/capture through.
Typings
The TypeScript definitions for the implemented web APIs can be found in the
lib.deno.shared_globals.d.ts
and
lib.deno.window.d.ts
files.
Definitions that are specific to workers can be found in the
lib.deno.worker.d.ts
file.
Deviations of other APIs from spec
Cache API
Only the following APIs are implemented:
- CacheStorage::open()
- CacheStorage::has()
- CacheStorage::delete()
- Cache::match()
- Cache::put()
- Cache::delete()
A few things that are different compared to browsers:
- You cannot pass relative paths to the APIs. The request can be an instance of Request or URL or a url string.
match()
&delete()
don't support query options yet.