6

EDIT - I've updated title and added answer, there are issues using . in URLs for Salesforce REST

I am writing a REST web service in salesforce to return information about accounts. I am finding that when I use an email address in the URI, I get a Salesforce error.

Here's some code to show the problem

@RestResource(urlMapping = '/showaccount/*') 
global without sharing class showAccount {

    @HttpGet
    global static String doGet() {
        String uriRequested = RestContext.request.requestURI;
        System.debug(uriRequested);
        return uriRequested;
    }
}

If I go ahead and make a rest call to the following URL:

/services/apexrest/showaccount/this_sort_of_key_is_fine

then the response is as expected, http code 200 and body of "/showaccount/this_sort_of_key_is_fine"

However if I call the URL and the last part looks like an email address, as follows

/services/apexrest/showaccount/customer@busy.com

then my rest code isn't executed by Salesforce and the response is http code 404 with a body of: [{ "errorCode": "NOT_FOUND", "message": "The requested resource does not exist" }]

The question how-does-salesforce-handle-wildcards-in-a-rest-urlmapping-property is interesting as it seems to me that my problem is also related to how Salesforce is finding the correct rest class from the supplied URL.

I have also found that if I change the urlmapping of the class to /showaccount/*/* then the class is successfully called when I use /showaccount/customer@busy.com/ (but note the trailing / which I would like to avoid).

So my question is

  1. is there a way to make this work so that I can use a call like /showaccount/[email address] and get a response?
  2. does this sound like a Salesforce bug?
  • 2
    For a REST API where I controlled both the client and the server, I used base 64 encoding to avoid this problem (as a pragmatic work-around for whichever part of the email address was causing the problem). But far from ideal for a public REST API. – Keith C Jun 4 '14 at 9:38
  • 1
    Sounds like an issue which should be raised with the SFDC team as that is a perfectly valid URL. I don't believe the client making the request should be forced to add the trailing slash or replace the . with %2E. – Mark Pond Jun 4 '14 at 17:08
  • Thanks @MarkPond, I agree. SFDC have said this is down to the regex they are currently using to map the URL to the resource. Hopefully this will be addressed in future. – Doug B Jun 5 '14 at 10:00
4

I have had a response from Salesforce support and I've also done a bit more experimenting. The problem comes from the . character not the @ and the word from salesforce was "using REST API .json and ,xml extension so there is a rule in load balancer that uses regex depending upon how many characters added after dot."

So the following examples are illustrative:

/services/apexrest/showaccount/bob@test          GOOD
/services/apexrest/showaccount/bob@test.co.uk    ALSO GOOD (the pieces after the . only 2 chars long)
/services/apexrest/showaccount/bob@test.com      ERROR 404
/services/apexrest/showaccount/bob@test.com/     GOOD

Looks like with the way that the regex is implemented you should be very careful if the URL can include the period character and terminate the URL with a / if possible

0

UPDATE: this answer is incorrect. Had considered deleting it, but it may still be usefull to indicate that this was not the problem.

Haven't actually tested this, but according to this question on stackoverflow , this RFC 2396 answer on stackoverflow and the W3schools article on URL Encoding I believe the @ character should be URL encoded, and that that is likely the cause of why Salesforce is mis-interpreting your http request.

  • 1
    Actually it's not the @ that causes it to choke, it's the period (.) So URLencoding doesn't work, if I use /showaccount/customer%40busy.com then I get the same error. However if I go to /showaccount/customer@busy%2Ecom Salesforce does find my resource. However it's not a standard encoding and I don't believe that this is correct REST behaviour. I would be forcing my clients to do a custom encoding which is not obvious. – Doug B Jun 4 '14 at 9:44
  • Thanks for the answer though Samuel :) – Doug B Jun 4 '14 at 9:54
  • 2
    W3schools should not be considered reliable. See w3fools.com. Quoting an RFC is definitely better. – sfdcfox Jun 4 '14 at 15:15

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.