HTTP Verbs
Content
Overview
ULM Cloud exposes services in compliance with the REpresentational State Transfer (REST) architecture that operates over the standard HTTP (RFC 2626) protocol. Therefore, ULM allows most API interfaces over common HTTP Verbs (or Methods) as specified by the HTTP Protocol.
HTTP Methods
The following table lists and describes the supported verbs as they relate to ULM Cloud, and to REST architecture in general.
| HTTP Method | Description |
|---|---|
| HEAD | Useful for determining if a resource exists, or for retrieving meta-information about a resource, without actually downloading the resource. Such information may include resource size, update, time, etc. exposed via specific header values. Also useful for clients that may employ auto-discovery of resources or where bandwidth could be an issue. |
| GET | Equivalent to a "read" operation, where a client fetches a specified resource (or multiple resources) from the server. The fetched resource can be optionally identified as well as filtered by request parameters, path parameters, headers, and the security authorization and/or role of the calling user. For example, the bulk of user management APIs require a standard user context (the user must be authenticated) to access the API. However, there are some cases where the user must be anonymous (e.g., invoking the Recover ID & Reset Password Processes) or have Admin authorization (for accessing Admin APIs). |
| POST | Creates a new resource. The content of the resource must be passed to ULM in the request body. Responses from the server may or may not include the created resource. |
| PATCH | Partially updates the specified resource with the properties and attributes being passed in the request body. Properties that are not passed remain unchanged. |
| PUT | Updates the identified resource with properties and attributes being passed via the request body. PUT operations, unlike PATCH, typically require that the entire resource is provided in the request body (both modified and unmodified properties included). In other words, the client must send the entire object, including properties and attributes that are not being updated, alongside those that are.
Note: ULM Cloud may prohibit the update of certain resources or specific properties via PATCH or PUT operations, as business rules may apply when these resources or properties change (e.g. password modification). In these cases, the user is expected to follow a specific ULM Process flow to update the resource and/or property. Documentation for individual APIs clarifies which properties can be updated using PATCH or PUT APIs. |
| DELETE | Removes the identified resource from ULM Cloud. DELETE operations may not always result in resources being deleted from the database for various reasons (i.e. legal compliance). In those cases, the resources instead are stored in a redacted or "deactivated" state. Resources removed via this operation cannot be restored, even if the resource has only been redacted or placed in a deactivated state. |
Revision History
| Version | Description |
|---|---|
| 2020.11 | Added this topic. |