# Single Endpoint Proposal

**URL:** <https://discuss.jsonapi.org/t/single-endpoint-proposal/823>\
**Category:** Uncategorized\
**Created:** [November 2, 2016, 7:53pm UTC](https://discuss.jsonapi.org/t/single-endpoint-proposal/823 "2016-11-02T19:53:15Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![andrewhenderson](https://sea2.discourse-cdn.com/flex016/user_avatar/discuss.jsonapi.org/andrewhenderson/32/115_2.png) [@andrewhenderson](https://discuss.jsonapi.org/u/andrewhenderson)\
**Post date:** [November 2, 2016, 7:53pm UTC](https://discuss.jsonapi.org/t/single-endpoint-proposal/823/1 "2016-11-02T19:53:15Z")

</div>

Has anyone explored using a single endpoint for their API?

On my team, we recently began using the `included` array for updating multiple resources in a single `PATCH` request:

`http://example.com/people/1`

```
{
  "data": {
    "type": "people",
    "id": "1"
    "attributes": {
      "first-name": "Mike"
    }
  },
  "included": [{
      "type": "comments",
      "id": "2",
      "attributes": {
        "body": "My updated comment!"
      }
    }
  ]
}

```

This made me realize that if we can update multiple resources using the `included` array as an entry point, our API can act similarly, sending and receiving a data array of mixed types – so long as each object has a `type` property and optionally an `id` when using `PATCH` or `DELETE`.

For example, if we want to create multiple resources we can `POST` to our single endpoint API:

`http://example.com/api`

```
{
  "data": [{
      "type": "people",
      "attributes": {
        "first-name": "Dan",
        "last-name": "Gebhardt",
        "twitter": "dgeb"
      }
    }, {
      "type": "comments",
      "attributes": {
        "body": "First!"
      }
    }, {
      "type": "comments",
      "attributes": {
        "body": "I like XML better"
      }
    }
  ]
}

```

A `GET` of various resource, even those which do not have a relationship, can look like this:

```
{
  "data": [{
      "type": "people",
      "id": "9"
    }, {
      "type": "comments",
      "id": "5"
    }, {
      "type": "comments",
      "id": "12"
    }
  ]
}

```

I realize this may require some reworking of the request/response object structure, however I believe this approach allows for an API that closely resembles [GraphQL](http://graphql.org/) and no longer requires the overhead of creating endpoints for every resource type.

![](https://us1.discourse-cdn.com/flex016/uploads/jsonapi/original/1X/540fc5008d946469855f57536c396c182a164d18.png)

---

<div class="post-metadata">

**Author:** ![ef4](https://sea2.discourse-cdn.com/flex016/user_avatar/discuss.jsonapi.org/ef4/32/215_2.png) [@ef4](https://discuss.jsonapi.org/u/ef4)\
**Post date:** [November 4, 2016, 3:06pm UTC](https://discuss.jsonapi.org/t/single-endpoint-proposal/823/2 "2016-11-04T15:06:22Z")

</div>

There is a lot of prior work and discussion on the best way to support multiple write operations in a single request. See for example [https://github.com/json-api/json-api/issues/795](https://github.com/json-api/json-api/issues/795)

I think the desire to avoid the “overhead of creating endpoints” misses the point that any server smart enough to serve arbitrary requests on a single endpoint in a performant way can just as easily auto-generate multiple endpoints instead. There is no real savings in trying to fit everything into a single endpoint – the difference is cosmetic.

One of the strengths of JSONAPI is that the server gets to be more picky about what access patterns it supports. Some access patterns are fiendishly more expensive to serve quickly than others. But nothing stops a JSONAPI server from offering fully-generic access just like a GraphQL server.

---

<div class="post-metadata">

**Author:** ![andrewhenderson](https://sea2.discourse-cdn.com/flex016/user_avatar/discuss.jsonapi.org/andrewhenderson/32/115_2.png) [@andrewhenderson](https://discuss.jsonapi.org/u/andrewhenderson)\
**Post date:** [November 4, 2016, 6:04pm UTC](https://discuss.jsonapi.org/t/single-endpoint-proposal/823/3 "2016-11-04T18:04:19Z")

</div>

Thanks for linking to that thread. I’ve quickly read through it, however I was unable to determine the leading proposal. Is it this proposal: [https://github.com/json-api/json-api/issues/1097](https://github.com/json-api/json-api/issues/1097)?

I found this [on the thread](https://github.com/json-api/json-api/issues/795#issuecomment-240385923) as well:

```
PATCH /articles HTTP/1.1
Host: example.org
Content-Type: application/tbd

[
  {
    op: 'add',
    data: {
      type: 'articles',
      attributes: {
        title: 'JSON API paints my bikeshed!'
      }
    }
  },
  {
    op: 'add',
    ref: {
      type: 'authors'
    },
    data: {
      type: 'authors',
      attributes: {
        name: 'dgeb'
      }
    }
  },
  {
    op: 'replace',
    ref: {
      type: 'articles',
      id: { path: '/0/data/id' },
      relationship: 'author'
    },
    data: {
      type: 'authors',
      id: { path: '/1/data/id' }
    }
  }
]
```

---

<div class="post-metadata">

**Author:** ![steveklabnik](https://sea2.discourse-cdn.com/flex016/user_avatar/discuss.jsonapi.org/steveklabnik/32/2_2.png) [@steveklabnik](https://discuss.jsonapi.org/u/steveklabnik)\
**Post date:** [November 7, 2016, 3:39pm UTC](https://discuss.jsonapi.org/t/single-endpoint-proposal/823/4 "2016-11-07T15:39:27Z")

</div>

> [@andrewhenderson](#):
>
> Has anyone explored using a single endpoint for their API?

Yes, many specifications do this. It’s against RESTful principles, though, as you lose a lot of things when you do it that way.