OECGI4 and REpresentational State Transfer (REST) (General,Web)
Created at 06 MAR 2017 01:28PM
OECGI4 and REpresentational State Transfer (REST)
One of the upgraded features of OpenInsight 10 will be OECGI4, the newest version of our web support routines. One of the enhancements to OECGI4 (available as both a Windows executable for Windows web servers, and as a PHP routine for Windows or Linux web servers) is additional support for some of the less well known "verbs" used in the HTTP/HTTPS protocol. When using OECGI to support or access web pages, the HTTP and HTTPS protocols use the "POST" and "GET" verbs to submit, and request, information respectively. These have been in common use since the World Wide Web first standardized on the HTTP/HTTPS protocols. But in addition to the familiar POST and GET, HTTP/HTTPS defines other verbs that can be useful when writing RESTful interfaces.
REST stands for REpresentational State Transfer, and is in a way the underlying principle of the Web. When a client makes an HTTP or HTTPS request from a server, the response from the server contains not only the specific information needed to answer that request, but also details that the client can use to get more information, all "bundled up" in the answer. For example, when a request for a web page is made, the web page may contain images, or stylesheets, or script calls. The client has no way of knowing, in advance, if there is one, or a hundred, images in the returned page – but the page itself contains the instructions the client can use to retrieve the images, or the style sheets, or the script pages. The page may even include the data and instructions needed for the client to retrieve other pages (via links, or via pagination). Because of its familiarity, this may seem simple and straightforward when it comes to web pages, but the concept (that nothing is "predefined", but rather everything is embodied in the responses) can be expanded upon to make much more advanced inter-operating systems.
REST can be used, not just for retrieving and updating web pages, but also to enable computer programs, as well as people, to interact with web services. By building a RESTful interface, a web service designer opens up their web site to the possibility of having other software query it for information, or update it with changes, thus allowing anyone else to put different user interfaces (if any!) on these interactions. While not required for REST, using HTTP and HTTPS, and the additional HTTP/HTTPS verbs, is currently the most common way of implementing this.
In addition to "POST" and "GET", HTTP/HTTPS (and OECGI4) support the verbs "PUT", "DELETE", and "PATCH." In the RESTful programming world, the "GET" verb is used to retrieve information – either about the other available interfaces this RESTful interface supports, or information about specific "objects". For example, if you were to create a customer maintenance web service, the "GET" verb might be used to retrieve the list of customers, or the information about a particular customer – or the list of commands that can be applied to those customer "objects". The "POST" verb is commonly used to create new "objects" – in our example, the "POST" verb might be used to create a new customer. "PUT" and "PATCH" both are commonly used to update existing "objects" – in our example, either "PUT" or "PATCH" may be used to change the customer’s phone number (PUT may wipe out any data in fields that aren’t specified, while PATCH should only update the specified fields). Finally, "DELETE" is most commonly used to remove "objects".
When using OECGI4, you can examine the request parameter to find the "request method" (defined in the INET_EQUATES insert), and – with the appropriate INET_XXX stored procedures – you can begin to implement your own web service.
Interested in learning more about RESTful programming? For additional information, please see the following resources:
http://stackoverflow.com/questions/671118/what-exactly-is-restful-programming
http://blog.octo.com/en/design-a-rest-api/