| Note |
|---|
This web page is under construction. |
Abstract
Following API calls handle any interactions within the building information model itself. In order to support multi tenancy in a proper way additional URL paths are to be used containing the team name and the project name.
...
The JSON objects used for input and output will be based on the IFC standard in terms of structure and naming. First of all it's necessary to have a pure API bound object model and second using a standard based approach.
Representational State Transfer (REST)
Representational State Transfer (REST) is a style of software architecture for distributed systems such as the World Wide Web. REST has emerged as a predominant web API design model.
...
The client begins sending requests when it is ready to make the transition to a new state. While one or more requests are outstanding, the client is considered in transition. The representation of each application state contains links that may be used the next time the client chooses to initiate a new state-transition.
Key goals of REST:
- Scalability of component interactions
- Generality of interfaces
- Independent deployment of components
- Intermediary components to reduce latency, enforce security and encapsulate legacy systems
| Panel |
|---|
REST's client-server separation of concerns simplifies component implementation, reduces the complexity of connector semantics, improves the effectiveness of performance tuning, and increases the scalability of pure server components. Layered system constraints allow intermediary proxies, gateways, and firewalls to be introduced at various points in the communication without changing the interfaces between components, thus allowing them to assist in communication translation or improve performance via large-scale, shared caching. REST lets intermediate processing by constraining messages be self-descriptive: interaction is stateless between requests, standard methods and media types are used to indicate semantics and exchange information, and responses explicitly indicate cacheability. |
RESTful architecture constraints
- Client-server separation: no data storage on the client, client and server can be developed independently;
- Stateless: no client context being stored on the server. Each request contains all necessary information to service the request;
- Cacheable: clients can cache responses;
- Layered system: a client doesn'n know if it is directly connected to the server;
- Uniform interface between clients and servers.
- Code on demand (optional): servers can change functionality of a client by the transfer of executable code.[1]
Database operations and HTTP calls
| Wiki Markup |
|---|
Full use of HTTP methods considered as RESTful. There are four types of the database operation defined for content manipulation: *Create, Read, Update, Delete (CRUD)*. Following HTTP methods implement these operations on persistent level\[2\]: |
Operation | SQL | HTTP |
|---|---|---|
Create | INSERT | POST |
Read | SELECT | GET |
Update | UPDATE | PUT |
Delete | DELETE | DELETE |
RESTful web API call structure
All necessary information for resource manipulation will be sent within a HTTP request. It includes
...