[SalesForce] Getting JSON_PARSER_ERROR while parsing JSON

EDITED: It works sometimes without any problem (even with the oldest Api 22.0 that supports RestResource) and sometimes incorrectly.

That depends on the order of classes sorted by the time of the last modification.

If you edit the class REST1.cls or generally that with the shortest urlMapping length (add a comment into) it starts to work as you expect.

It is not exactly incorrect, because * matches any string with any number of /. It seems that the text "the patterns with wildcards... select the longest (by string length)" should be understand only "the longest string before the wildcard". The order of compared matching is not explicitely defined by docs if these parts are the same. They mean only: /word/* is a longer and better match than /*.

They want to provide a fast service. Therefore they probably need firstly to do a coarse match by an index, then to try classes ordered by this index until the first match is found. If you can find a good index expression than it can be probably fixed, but it is much complicated by rules about the final slash. I'm skeptical of anything, except for asking a possible very small improvement in documentation.

Tested code exemples:
REST1

@RestResource(urlmapping='/invoices/*/')
global class REST1 {
    @HttpGet
    global static String getClassName() {
        return 'REST1';
    }
}

REST2

@RestResource(urlmapping='/invoices/*/totals/')
global class REST2 {
    @HttpGet
    global static String getClassName() {
        return 'REST2';
    }
}

REST3

@RestResource(urlmapping='/invoices/*/related/')
global class REST3 {
    @HttpGet
    global static String getClassName() {
        return 'REST3';
    }
}

It is better and more universal to use urlMapping string without the final slash, but is is not important for this question. Example:

@RestResource(urlmapping='/invoices/*')

It can catch both /invoices/something/ and /invoices/something, while the mapping with the final slash requires only this one. Every example in Apex docs (e.g. the qouted above) is without any final slash.

**EDITED ** because the problem was not initially reproducible.

Because you are manually deserializing you do not need to put the "req" wrapper in your JSON. This is only required when Salesforce is doing the deserializing for you with the method signature so that it knows what top level variables to assign the values to.

Note that you do not necessarily need to deserialize into a wrapper class either: you can deserialize straight into your list of AMSAccts objects. Here is a small sample of what the JSON would look like in the two approaches:

Using Wrapper

JSON

{"AMSAccts": [{"accid": "001"}, {"accid": "002"} ... ]}

APEX

AMSAcctsWrper accParse = (AMSAcctsWrper)System.JSON.deserialize(req, AMSAcctsWrper.class);

Straight To List

JSON

[{"accid": "001"}, {"accid": "002"} ... ]

APEX

List<AMSAccts> accParse = (List<AMSAccts>)System.JSON.deserialize(req, List<AMSAccts>.class);

As you can see, when your JSON is an array you can just start it with an opening brace. The second approach assumes that you move AMSAccts to a top level class. If you left it in the wrapper you would need to reference it as AMSAcctsWrper.AMSAccts.

Hope this helps!