Web Service vs. API
Shawn Beasley07. May 2019 | Miscellaneous
The practical examples presented in our technical blog (blog.otrs.com) and now in the expert category in our FAQ blog section serve as a source of ideas and documentation to show what is theoretically possible with OTRS in concrete scenarios or sometimes even for more exotic configurations. All configurations presented here were developed under laboratory conditions as a proof of concept.
We can only guarantee testing and implementation of these concepts to be error-free and productive if implemented in a workshop with one of our OTRS consultants. Without this, the responsibility lies with the customer himself. Please note that configurations from older OTRS versions may not work in the newer ones.
OTRS, as a glue-ware, offers you the flexibility to maintain service-relevant information anywhere. Retrieval of the information, and providing service request-related data to third parties, is simple. A web service, known as the Generic Interface, has been the answer to this since its introduction in OTRS 3.1. The web service provides access via HTTP by means of SOAP or REST to the internal OTRS API. The OTRS API is written in Perl, and by using the web service operations, standardized communication is possible. It’s not necessary to understand how the Perl API works in order to use internal functions of OTRS: Instead, operations are provided which can be made available to external systems or used to request information from these systems.
Learn how our new REST API can make simple integrations faster than ever.
The major difference is that our API is now forward-facing, as opposed to having to access the Perl API via REST Operations. The middle man has been cut out. There are advantages and drawbacks. We will focus on the advantages, which include:
- Speed of deployment
- Zero configuration
- Standardized documentation
- High flexibility
- Increased security
The external interface’s front-facing RESTful API is available out-of-the-box with OTRS 7. The Generic Interface needs no configuration, as was needed in the past, because the endpoints and network transport are already defined. Perl is still under the hood, but instead of using special Perl Operations (limited functionality) provided the by Generic Interface, each endpoint is pre-defined (eg., Facebook, Google, etc). The documentation for the endpoints is available online and updated as new versions are built. The API documentation conforms to today’s API documentation standards in terms of how it is designed, delivered and easy-to-consume with examples and response codes for quick reference. You now have more flexibility than ever for accessing information which was not previously available with Generic Interface operations like customer user profile (/api/customer/account/personal-preferences information) and form data requirements (/api/frontend/external/form/ticket).
A simple ticket create can now be performed with very little effort. Authentication is sent in the header (make sure you generate a token /api/customer/auth/login), or it can be alternatively stored in a cookie. A payload like this is enough to create a ticket.
I look forward to hearing about your use cases.
“Man invented language to satisfy his deep need to complain.”