Managing REST Services
Sentinet manages REST APIs similarly to SOAP services and provides a unified and consistent approach to their management. At the same time, there are some differences between managing REST APIs and SOAP services. This chapter describes these differences (see the Managing SOAP Services and Managing Virtual SOAP Services chapters in this guide for the most common aspects of managing REST and SOAP services).
Registering REST Services
REST service (or a REST API) in Sentinet is still a service. It has operations, endpoints and endpoint policies just like a SOAP service, but REST services do not have service interfaces, because this concept is applicable to SOAP services only. It is normal to interpret RESTful services as resource-oriented APIs. Sentinet allows for very flexible interpretation of what REST services and operations are, including a resource-oriented approach.
A REST service may have one or more endpoints. The endpoint address is always the common part of all service operations' addresses. For example, if the service endpoint address is http://myserver/myapi/v1, then the full service operation addresses might be (common part is shown in bold font):
http://myserver/myapi/v1/Operation1?param1={param1}¶m2={param2}
http://myserver/myapi/v1/Operation2?param3={param3}¶m4={param4}
http://myserver/myapi/v1/Operation3?param5={param5}¶m6={param6}
Note: when a REST API is registered manually (see Manual Registration chapter below in this Guide), the Sentinet User can choose to define a common part of the service endpoint address. In the example above, a service endpoint address could have been defined as just http://myserver/myapi. While the full service operation addresses are still the same, the common part of these addresses is now different:
http://myserver/myapi/v1/Operation1?param1={param1}¶m2={param2}
http://myserver/myapi/v1/Operation2?param3={param3}¶m4={param4}
http://myserver/myapi/v1/Operation3?param5={param5}¶m6={param6}
With this second approach of defining endpoint address a new service operation http://myserver/myapi/v2/Operation4?param1={param1}& param2={param2} can be made part of the same service version, but with the first approach it cannot because all operation addresses in that case must start from http://myserver/myapi/v1.
Every service operation is always described by its single Request message description, and by one or more different Response messages and their descriptions.
For example, figure above shows some Petstore API with 10 operations, and one endpoint. Operation findPetsByStatus is defined by a single Request message and two Response messages.
An operation's Request message is described by a unique combination (within the service definition) of a Uri Template, HTTP Verb (such as GET, PUT, DELETE, etc.) and optional list of required HTTP Headers. Effectively, the uniqueness of this combination allows Sentinet to match request messages against service operations. You can always assume that operation's Request message description is what ultimately identifies operation itself.
