Long running jobs or asynchronous processing

1

Hello

I’ve initialy open an issue on github about this point, but discourse seems a better place to talk about this.

I was wondering if it’s plan to write specs when doing asynchronous processing. Maybe it’s completely irrelevant…

If not, will love to discuss about it. I’m writing Blueprint API and try to write proper asynchronous processing with the Json-API spec in mind.

  • Posting return :
HTTP/1.1 202 Accepted
Location: http://example.com/photos/queue/5234
Content-Type: application/vnd.api+json

Does response need a body with more informations ? Seems enough for me.

  • Get status
HTTP/1.1 200 Ok
Content-Type: application/vnd.api+json

{
  "links": {
    "self": "/photos/queue/5234"
  },
    "data": {
      "type": "queue job",
      "id": "5234",
      "status": "Process failed, see errors",
      "errors": [
      {
        "code": "too_long",
        "field": "/photos/title"
      },
      {
        "code": "invalid_format",
        "field": "/photos/file01"
      }
      ]
    }
}
  • If success
HTTP/1.1 303 See other
Location: http://example.com/photos/4577
Content-Type: application/vnd.api+json

Thanks in advance.

2

Yeah, this is a pretty common way to do it. I would see this kind of thing as a reccomendation more than in-spec itself, as it’s just basically using HTTP in the proper way…

3

Thanks for your answer Steve. Maybe something below #crud-creating-responses-202?

I can propose something here.

4

This general approach makes sense as a recommendation. We’re keeping recommendations in their own section, separate from the spec: http://jsonapi.org/recommendations/

5

Thanks Dan. Will write something for a recommendations

6

I’ve just make a PR for the recommendations : https://github.com/json-api/json-api/pull/792