| <!-- |
| /*************************************************************************************************************************** |
| * Licensed to the Apache Software Foundation (ASF) under one or more contributor license agreements. See the NOTICE file |
| * distributed with this work for additional information regarding copyright ownership. The ASF licenses this file |
| * to you under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance |
| * with the License. You may obtain a copy of the License at |
| * |
| * http://www.apache.org/licenses/LICENSE-2.0 |
| * |
| * Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an |
| * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the |
| * specific language governing permissions and limitations under the License. |
| ***************************************************************************************************************************/ |
| --> |
| |
| User Interfaces (UI) vs. Developer Interfaces (DI) |
| |
| <p> |
| An important distinction needs to be made about the HTML representations produced by the REST |
| API. These should not be considered User Interfaces, but rather Developer Interfaces. |
| </p> |
| <p> |
| UIs should hide the end-user from the underlying architecture. |
| The audience generally consists of non-technical people not interested in how the UI works. |
| </p> |
| <p> |
| DIs, on the other hand, should NOT hide the end-user from the underlying architecture. |
| Instead, it's a thin veneer over the REST interface with the following goals: |
| </p> |
| <ul class='spaced-list'> |
| <li>Make it easy for the developer to explore and understand the REST API. |
| <li>Make it easy for the developer to debug the REST API using simple tools (hopefully just a browser). |
| </ul> |
| <p> |
| As a result, the following guidelines are recommended: |
| </p> |
| <ul class='spaced-list'> |
| <li> |
| Use titles/descriptions/asides to describe why the REST interface exists. |
| A developer knowing little about it should be able to access it with a browser and quickly |
| understand what it is and how to use it. |
| <li> |
| Don't hide the raw data! |
| The HTML view should simply be considered an easier-to-read representation of the data normally |
| rendered in JSON or some other format. |
| <li> |
| Limit your use of Javascript! |
| You can use it sparingly if you want to implement something simple like a pull-down menu to |
| simplify some debug task, but remember that your audience cares more about interacting with your |
| service programmatically using REST. |
| Remember that the HTML is just icing on the cake. |
| <li> |
| Don't use it to implement a Web 2.0 interface! |
| If you want a Web 2.0 UI, implement it separately ON TOP OF this REST interface. |
| The architecture is flexible enough that you could in theory pull in and use jQuery, React, |
| Angular, or any number of sophisticated Javascript UI frameworks. Resist the urge to do so. |
| </ul> |