In general, a RAMADDA URL can be specified as:

https://<hostname>/<base path>/<api path>/<entry path>?entryid=<entry id>
e.g.:
https://ramadda.org/repository/entry/show/Home/RAMADDA+Examples?entryid=a96b9616-40b0-41f5-914a-fb1be157d97c

The base path (by default /repository) is the same for the entire repository. This is set with the ramadda.html.urlbase property. The API path determines what service is being invoked. When viewing an entry the default path is /entry/show. This supports a number of result encodings described below. Other paths include:

/entry/get  -  return the file

The entry is identified by the entryid URL argument:

https://ramadda.org/repository/entry/show/Home/RAMADDA+Examples?entryid=a96b9616-40b0-41f5-914a-fb1be157d97c

The path to the entry (e.g., /Home/RAMADDA+Examples) is optional if the entryid argument is provided. However, if the entryid argument is not provided then RAMADDA will use the path:

https://ramadda.org/repository/entry/show/Home/RAMADDA+Examples

Though this works we kindof discourage this approach because if you change a name or location then any links the entry would break.

Entry Output

When viewing an entry in RAMADDA one can specify any number of encodings or views of the entries with the output URL argument: Basic HTML display:
https://ramadda.org/repository/entry/show/Home/RAMADDA+Examples?entryid=a96b9616-40b0-41f5-914a-fb1be157d97c&output=html.info
GeoRSS:
https://ramadda.org/repository/entry/show/Home/RAMADDA+Examples?entryid=a96b9616-40b0-41f5-914a-fb1be157d97c&output=rss.full
ATOM-XML:
https://ramadda.org/repository/entry/show/Home/RAMADDA+Examples?entryid=a96b9616-40b0-41f5-914a-fb1be157d97c&output=atom
Map:
https://ramadda.org/repository/entry/show/Home/RAMADDA+Examples?entryid=a96b9616-40b0-41f5-914a-fb1be157d97c&output=map.map
Google Earth:
https://ramadda.org/repository/entry/show/Home/RAMADDA+Examples?entryid=a96b9616-40b0-41f5-914a-fb1be157d97c&output=map.gemap
CSV:
https://ramadda.org/repository/entry/show/Home/RAMADDA+Examples?entryid=a96b9616-40b0-41f5-914a-fb1be157d97c&output=default.csv
CDL/NCML
https://ramadda.org/repository/entry/show/Home/RAMADDA+Examples/Science+Data/Gridded+Data/elev.nc?output=data.cdl

Authenticating Programmatically

The below has access control set to only allow user "foo" with password "bar" to access the entry. If from the command line one were to view the CSV listing of the entry it would fail.

curl --fail -k -o test.txt "https://geodesystems.com/repository/entry/get?entryid=03f21209-785d-48a8-8d79-bb92a3ad67ee"

First off, the return from a failed call would be in HTML. To specify an alternative response format you can add the response argument -

curl --fail -k -o test.txt "https://geodesystems.com/repository/entry/get?entryid=03f21209-785d-48a8-8d79-bb92a3ad67ee&response=json"
or:
curl --fail -k -o test.txt "https://geodesystems.com/repository/entry/get?entryid=03f21209-785d-48a8-8d79-bb92a3ad67ee&response=xml"
or:
curl --fail -k -o test.txt "https://geodesystems.com/repository/entry/get?entryid=03f21209-785d-48a8-8d79-bb92a3ad67ee&response=text"

To authenticate you can do one of 2 things. First, any request can have the url arguments auth.user and auth.password and the authentication is done on the fly when handling the request. The drawback is that your username/password can show up in log files unless you do a POST.

curl --fail -k -o test.txt "https://geodesystems.com/repository/entry/get?entryid=03f21209-785d-48a8-8d79-bb92a3ad67ee&response=json&auth.user=foo&auth.password=bar"

You can also login and get the session id then use that.

curl --fail -k  "https://geodesystems.com/repository/user/login?&response=json&user.id=foo&user.password=bar"
> {"ok":"8d4a5cb3-eaa0-4561-926a-f9a9f8ac73b7_0.1941947596962228"}

curl --fail -k -o test.txt "https://geodesystems.com/repository/entry/get?entryid=03f21209-785d-48a8-8d79-bb92a3ad67ee&response=json&sessionid=8d4a5cb3-eaa0-4561-926a-f9a9f8ac73b7_0.1941947596962228"

Adding APIs in plugins

The API into RAMADDA is declaratively defined with one or more api.xml files:

<api>
  <property name="admin" value="false"/>
  <property name="cancache" value="true"/>
  <group handler="repository">
      <api request="/entry/show"             method="processEntryShow"    name="Home" toplevel="true" ishome="true"/>
      <api request="/entry/show/*"           method="processEntryShow"/>
...
  </group>
  <group handler="metadatamanager">
      <api request="/metadata/list"       method="processMetadataList"/>
      <api request="/metadata/form"       method="processMetadataForm"       actions="edit"/>
...
  </group>
  <group handler="admin">
      <api request="/admin/sql"          method="adminSql"           admin="true"/>
      <api request="/admin/startstop"    method="adminDbStartStop"   admin="true"/>
...
  </group>

</api>
developer/api_dummy.xml

Note: The above file has "_dummy" appended to it. To actually use this in the IDV change the name so it ends with api.xml. This file can be organized as a set of group tags that define a handler and contain a set of api. The api tag can also define a handler. The handlers are one of: usermanager, admin, harvestermanager, actionmanager, accessmanager, metadatamanager, repository.

External classes can be used as handlers by providing the full class name. These handlers need to implement RequestHandler and need to have a public constructor that takes as argument the Repository object and the xml api Element.

The api tag contains a path attribute which is used the the url path. e.g., the main way to view an entry is the "/entry/show" path. The url ends up looking like:
<repository suffix>/entry/show?id=<entry id>
The method attribute is the method name on the handler that is called. These methods have the signature:

public Result processEntryShow(Request request) throws Exception {
    ...
}

They take a Request object and return a Result object.