Skip to main content

 

Documentation & User Guides | FotoWare

Troubleshooting requests to the FotoWeb API

This topic provides some guidelines to help you troubleshoot requests to the FotoWeb API. Please follow these guidelines before contacting Support, as Support will probably ask you about the results of the below tests.

Check that FotoWeb is responding

If you are just getting started using the API, check the following:

(Note that this section applies to the FotoWeb REST API, not to the legacy APIs (ArchiveAgent, etc.))

  • Connect to FotoWeb using a browser to make sure the server is set up correctly and answering.

    The problem might not be related to using the API at all, and resolving it might therefore not require any knowledge of the API.

  • EITHER you are using the correct API key in the correct header OR Guest access is enabled (Guest user is licensed and not locked out) on the site.
  • (If not using the public API) an API license is activated on the server
  • (if using server-to-server user authentication) the user has the "API Access" group permission.

Step 1: Inspect the Request

Some REST clients output detailed information about a request and the response received from the server. If this is not available, then the next best option is to route the request through Fiddler. This requires doing the following:

  1. Install and run Fiddler
  2. Change the application to use the system proxy for making requests, or explicitly use localhost:8888 as the proxy server (Fiddler listens on port 8888 and registers itself as the system proxy)
  3. If possible, use HTTP (not HTTPS) for debugging and development. If the server only allows HTTPS, or HTTP cannot be used for security reasons, then it is possible to enable HTTPS decryption in Fiddler. Please use this carefully, as it requires accepting Fidler's security certificate on the development client! Make sure to remove this certificate whenever you are done debugging! (You are basically temporarily allowing Fiddler to man-in-the-middle-attack communication between your application and the server!)

Fiddler is only available on Windows. For other platforms, there are the following options:

  • Use a different debugging proxy, such as Charles (Mac and Windows)
  • Set up Fiddler on a separate Windows machine, allow other computers to connect to Fiddler and route requests through it.

For example, see How can I debug requests sent by mobile apps to FotoWeb?

For example, if you are using curl, you can use the following additional command-line option to use Fiddler:

curl -x localhost:8888

The following information about the request and response may be helpful:

  • Status code: 400-499 means the request was somehow invalid, 500-599 means there was an error on the server side.
  • "Web View": If the response was not JSON data but HTML (which should not happen under normal circumstances), this can give some hint about what happened.
  • Request and response headers

It is possible to select one or more requests in the list view in Fiddler and save them as a .sazfile. FotoWare support may ask for such files, as they are the best and easiest way to communicate what the request and response looked like. Please, if possible and convenient, always send .saz files rather than copying and pasting requests and responses. This is also always much better than sending us application code.

Step 2: Check that the error actually comes from FotoWeb

If the response is not JSON data, then chances are the request comes from a reverse proxy or front-end cache or other component between the client and FotoWeb.

The "Web View" tab, as well as response headers, can provide hints on this.

Step 3: Check the Logs

When requests fail, the FotoWeb server typically logs an error. This is the case, particularly, for server-side errors (status code 500-599). In case of a server-side error, there MUST be a log message. No log message means that the server either crashed, or that there is a bug. You may also want to check for crash dumps.

FotoWare Support will most likely ask for server logs if the error cannot be explained using the request and response data alone.