Subject: [scim] JSON format for Error

From: Steve Moyer <[email-masked]>
Date: Fri, 15 Nov 2013 08:24:38 -0500 (EST)

According to section 3.9 of the API document, each error contained within the JSON should MUST contain a string indicating the HTTP response code for that error.  I have two questions:

1)  When there's more than one error in the error list, which HTTP response code should be returned in the HTTP status code if they don't all have the same value?

2)  Most systems treat HTTP status codes as integers - Is there some reason these are specified as JSON strings?

Thanks,

Steve

--

---

From: Kelly Grizzle <[email-masked]>
Date: Mon, 18 Nov 2013 21:11:34 +0000

Hi Steve ... we're looking at changing error responses.  See ticket #46 for the details - http://tools.ietf.org/wg/scim/trac/ticket/46.

> 1)  When there's more than one error in the error list...

We are considering constraining this to a single error in ticket #46.  I'm curious how you are using multiple errors.

> 2)  Most systems treat HTTP status codes as integers - Is there some reason these are specified as JSON strings?

You're right.  The new proposal would use integers instead of strings.

--Kelly

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Steve Moyer
Sent: Friday, November 15, 2013 7:25 AM
To: [email-masked]
Subject: [scim] JSON format for Error

Thanks,

Steve

--

_______________________________________________
scim mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/scim

---

From: Steve Moyer <[email-masked]>
Date: Mon, 18 Nov 2013 17:06:36 -0500 (EST)

Kelly,

Changing the system to use integers for the HTTP status code would be great.

The only case where we can conceivable have multiple errors returned from our system is when a resource is being created or updated.  We have certain (additional) fields that we require, and we also validate the format of some of the fields, so the ability to return a list of validation errors (the description part of the current Errors list) is perfect for that.  I also like the idea of returning the code via JSON, so following the example in the issue you reference, we might use something like this:

HTTP/1.1 400 Bad Request
Content-Type: application/json
Content-Language: en

{
    "code": 400
    "Errors":[
        "This system requires that the familyName attribute is not null and non-empty",
        "This system requires that at least one valid e-mail address is provided",
        "This system requires that a security question is selected",
        "This system requires that a security answer is entered"
    ]
}

In this case, all the validation errors would be considered Bad Requests, so we don't need the code to be included in every Error.

Steve

----- Original Message -----
From: "Kelly Grizzle" <[email-masked]>
To: "Steve Moyer" <[email-masked]>, [email-masked]
Sent: Monday, November 18, 2013 4:11:34 PM
Subject: RE: JSON format for Error

--Kelly

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Steve Moyer
Sent: Friday, November 15, 2013 7:25 AM
To: [email-masked]
Subject: [scim] JSON format for Error

Thanks,

Steve

--

---

From: Keith Uber <[email-masked]>
Date: Tue, 19 Nov 2013 06:56:22 +0000

If one error code can indicate multiple error conditions and error text is used to describe this, please consider localization

---

From: Kelly Grizzle <[email-masked]>
Date: Tue, 19 Nov 2013 14:27:49 +0000

The proposal in ticket #46 would use localized values for the user-friendly error message returned in the "title" attribute.

---

From: Steve Moyer <[email-masked]>
Date: Tue, 19 Nov 2013 10:09:22 -0500 (EST)

I should have noted that I omitted everything that wasn't relevant to explaining how we'd use multiple descriptions.  I don't see an issue with i18n.

Steve