Flood Risk Evaluator API: Documentation



*Water Depth is in feet.
*Water Percentage: Water percentage must sum to 100 and must always be inserted in the URL. If the total WP number exceeds the 100, then there's an error popup. Keep in mind that whatever the water percentage is for one unit, the number by default will be 100 (as logically expected).

Below is a Request Example:

Request=GetDamage&format=xmL&id=1&BC=1&dc=105&bo=RES1&yb=1987&st=1&ft=2&ba=0&ga=0&wd=3.5&wp=79

The value of the Request key is GetDamage, the wanted format is XML, the ID equals to 1 and so on. A note here would be that our URL manages the URL as case insensitive; which makes it more “hackable” and easy to manipulate, although a case-sensitive URL would make sense in some other applications. A more complex request:

RequestRequest=GetDamage&format=xmL&id=1&BC=1&dc=105&bo=RES1&yb=1987&st=1&ft=2&ba=0&ga=0&wd=3.5&wp=79&id=2&BC=1&bq=Average&bo=RES1&yb=2000&st=1&ft=2&ba=0&ga=0&wd=3.1&wp=100

As we can see here, we can declare multiple buildings as long as we give different ID of the type of building. If a REST application feels logic & normal even for the end user, then it can be said that it successfully applies the RESTful principles. Usually, RESTful URI’s can be described by a Regular Expression.

Pseudo REGEX:

Request=[]XML|JSON\&[ID=[0-9]&BC=[0-9]&DC=[0-9]&BO=BO_TABLE_VARS&YB=[0-9]&ST=[0-9]&FT=[0-9]&BA=[0|1|2]&GA=[0|1]&WD=[0-9]&WP=[0-100]&[BQ=BQ_TABLE_VARS]0-1&BV=[0-9]0-1]+



We can also view our REST request as a tree:




As we can see, our request is split to several parts that altogether express our initial request. Note that this isn't the request body -- it's just a URL. This URL is sent to the server using a simpler GET request, and the HTTP reply is the raw result data -- not embedded inside anything, just the data you need in a way you can directly use.