Do I Use the REST or Server-Side API?

This is a classic question, and there's oftentimes not a 100% correct answer for you, depending on all kinds of factors.  However, there should always be a better answer.

In general, you should know that like most ASP.NET REST API's, our REST API is dependent upon the benefits and limitations that come with IIS and the IIS pipeline.  Meaning, that every REST API request is treated like a brand new request, and as such, often results in a higher overhead in each individual request.  This may result in a perceived performance issue on some sites, depending on how you implement the REST API.  

The REST API also has nearly everything that you'll need for many integration scenarios, but it's not likely to have everything that you'll need.  At some point, it may be missing parameters or endpoints that are specific to your use case.  There are ways to workaround this and we often are adding capabilities to the REST API, but it's useful to know.

In contrast, the server-side API will always have everything that you need, and due to its nature, it comes with a higher level of caching and perceived performance.  Also, since it's raw server-side code, you'll likely have a lot more flexibility in how you can work with it.  However, the server-side API requires a valid HTTP context in order to work with it in any effective scenario.  There's ways to work around this too, but it's a very useful thing to consider just the same.  

In the end, neither method is better than the other all of the time.  Like with any project, you need to determine what your current project needs, and which method best achieves those goals.  

Here's some general guidelines...

Use the REST API for:

• Apps (mobile, desktop, etc.)
• Offsite application integrations
• Scheduled jobs
• Ad hoc console apps

Use the Server-Side API for:

• On-site application integrations
• Complimentary module integrations
• Theme integrations
• Viewset integrations
• In general, any extension point