K Obtaining 200 OK SIP Notify (Presence Info) 200 OK HTTP Post SIP Publish 201 Created 200 OK Publishing (Resource URI) (SIP-Etag) HTTP Put (Resource URI) SIP Publish Refresh or 200 OK 200 OK Re-publishing HTTP Delete SIP Publish (Resource URI) (Expires = 0) Delete 200 OK 200 OK Figure 3.4 Example REST API for Presence. Service Delivery Platforms intrinsic features of REST, that is, it works with resources, for example, presentity. The resources can be freely defined and can keep states (e.g., presence status). The client acts on the resources: get, modify (e.g., state), delete, and SO on and these resources are always univocally identified by URIs. The actions on the resources are performed through standard HTTP verbs: GET, POST, PUT, and DELETE, which has a specific meaning in the context of each API. For instance, in this pres- ence example HTTP GET is utilized to retrieve a presentity's status; HTTP POST can be used for publishing presence information; HTTP PUT for refreshing soft- state presence information; and HTTP DELETE to erase this softstate informa- tion. The application of REST principles to IMS Presence is thus immediate. Aside from the protocol aspects, the API exchange information between the API client and the API server. To accommodate the expectations of a bigger number of developers, APIs shall provide different data formats SO the user can select the most suitable one according to the programming language and development tools the user utilizes. The IMS Exposure Layer at least shall provide the following data formats: Client-server scenario: XML, Atom 1.0, RSS, and JSON. Server-server scenario: XML, Atom 1.0, RSS, and serialized PHP. This allows utilizing the remote APIs and the exchanged data from most of the languages being utilized in the Internet. Furthermore, the Telecom Exposure Layer might be simpler to utilize if the developers are provided with language libraries that handle the API client behavior. That means that the developer does not need to deal with HTTP request and response co