Strange bug with REST API

Hello All,

I had an issue this morning while working with my REST API. If I tried to use the JavaScript app.api.call function, as documented here Documentation Class: Api, I ran into the error: "no method" with the message "Could not find a route with x elements". I scoured the internet, looking for anything I could find to make the app.api.call work, but in the end I settled for making my own call to my custom REST API.

So, in short, when using my own calls:

if I use fetch plainly to my custom endpoint: error that says needs authentication

When I use fetch to grab a token using the rest/v10/oauth2 endpoint: get token

Use token  in headers to custom endpoint: works correctly.

When using sugar calls:

Doesn't ask for authentication, just says Could not find a route with x elements.

I have tried using the same exact url that I currently use in my fetch AND postman as the app url, and I still get the error.

I have tried putting different values into the third argument below, such as null, empty object, query strings, etc. Nothing works. I can confirm that the function itself works because it triggers the error block.

app.api.call('POST', app_url, <null or empty object for now>, {
   success: data => {
      console.log(data);
   },

   error: err => {
   console.log('error in fetch email, ' + err);
   }
});

Just to re-iterate, postman and my own fetch work via the url I put in, but not using the sugar app.api.call. It would be nice to avoid having to send refresh tokens or auth by using the already existing user authentication, but maybe I am wrong in assuming that.

Thank you for any insight.

  • When calling the api from your javascript are you building the url as described here?

    Documentation Class: Api 

    e.g. 

    var url = app.api.buildURL("Contacts", "duplicateCheck", null, {});

    e.g. I have custom a GET api that returns currency based on country:

    var url = app.api.buildURL('/ERPCurrencyLookup/' + address_country);

     

    FrancescaS

  • I tried both 

    var app_url = app.api.buildURL('/<endpoint name>/<endpoint method>?=' + <put querystring here>);

    as well as

    var app_url = app.api.buildURL(<endpoint name>, <endpoint method>);

    I read in the documentation The attributes hash must contain id of the resource being actioned upon for record CRUD and relatedId if the URL is build for relationship CRUD. I don't really have those as it is a custom endpoint.

    and wasn't sure whether I needed those for my use case. I was using query strings for now during testing.

    Quick question from the original post though, somewhat related. If I do end up getting this to work through Sugar's method of api calling, will it bypass the authentication requirement of getting tokens and refreshing them? (Instead, using the user's own base token). I honestly feel a lot more comfortable using JavaScript's Fetch API, it's a lot better documented and usable anywhere and not just within an obscure platform.

  • I actually found the issue. Apparently the app.api.Call method actually remaps 'POST' as 'update'. My fault, but I don't really understand why this would be done instead of just using the proper http methods. Why add another layer of confusion? I find myself asking this question a lot when dealing with Sugar. Thank you for trying.

  • If you are calling the api from within the application, the user is authenticated and already has a token, you will not need to request another or refresh it. The app takes care of that.

    I believe you should use POST to create a new record, PUT to update an existing one. Clearly if you are updating it will need the id of the record to update. But if you are creating a new one, you won't have an id until after it is created.

    Perhaps it would help if you could share your custom API. I totally understand if you can't.


    Francesca

  • Oh no, I figured it out as I replied above. Apparently if you don't use

    read, create, update, delete 

    In Place of

    GET, POST, PUT, DELETE.

    Then app.api.call will actually only send GET requests instead of POST requests (Despite using 'POST' as the first argument). I assumed (wrongly) that Sugar would stick to the same CRUD commands that have been standardized and used for a long time, instead of abstracting them away (for what purpose I have no idea).