Page History
...
Code Block |
---|
Response = HTTP_Resource_Services(Service, Param1, Param2, Param3, Param4, Param5, Param6, Param7, Param8, Param9, Param10@Service, @Params) |
Returns
The meaning of the response value depends on the service.
Parameters
Parameter | Description |
---|---|
Service@Service | The name of the service being requested. Required. |
Param1 - Param10@Params | Generic parameters. Refer to a specific service to determine the actual parameters used. |
Remarks
The SRP HTTP Framework supports two popular JSON friendly data formats: HAL and Schema. HAL stands for Hypermedia Application Language and is an emerging format that implements the HATEOAS constraint of REST. There are other formats that are also emerging and none hold dominance at this point. Likewise, JSON itself stands alongside XML as a widely accepted general purpose format for representing resources. Therefore, if you need or prefer to use another format then you are welcome to extend HTTP_JSON_Services
(in case you want to use a different hypermedia format, such as Collection) or write a new service such as HTTP_XML_Services
(in case you want to use a different data format, such as XML).
Schema is a meta-data format. It is used to notify clients what kind of data is available, which is handy when user interfaces need to be dynamically built. Schema can be used to define if a prompt is text, numeric, date, combobox, Boolean, etc. Like HAL, Schema is also an emerging format. There are others that may be better suited to your needs.
Services
HTTP_Resource_Services
is a helpful application service module that web service routines can use to perform common database operations. This works well for web services that are tightly associated with a single database table. For example, a URL with /customers
is likely to be directly linked to a CUSTOMERS database table.
Both the included HTTP_Users_Services and HTTP_Contacts_Services sample web service routines make use of HTTP_Resource_Services
.
Services
Service | Description |
---|---|
GetObject | Usage: Comments: Returns: |
GetObjects | Usage: Comments: Returns: |
ParseResource | Usage: Comments: Returns: |
AddProperty | Usage: Comments: Returns: |
AddProperties | Usage: Comments: Returns: |
AddSubProperty | Usage: Comments: Returns: |
AddSubProperties | Usage: Comments: Returns: |
AddSubResourceObject | Usage: Comments: Returns: |
AddSubResourceObjects | Usage: Comments: Returns: |
AddSubResource | Usage: Comments: Returns: |
AddSubResources | Usage: Comments: Returns: |
AddLinkRelation | Usage: Comments: Returns: |
AddLinkRelations | Usage: Comments: Returns: |
AddEmbeddedResources | Usage: Comments: Returns: |
AddFormAction | Usage: Comments: Returns: |
GetSerializedResource | Usage: Comments: Returns: |
LoremIpsum | Usage: Comments: Returns: |
GetURLTemplate | Usage: Comments: Returns: |
GetDatabaseItem | Usage: |
Comments: Returns: | |
GetDatabaseItems | Usage: Comments: Returns: |
DeleteDatabaseItem | Usage: |
Comments: Returns: |
PutDatabaseItem | Usage: |
|
Comments: |
To conform to the requirements of the PUT method, the entire resource will be replaced with the content being passed in, even if only a few properties (e.g., database columns) are being updated. Thus, it is assumed that both changed and unchanged properties will be passed into the request body. Returns: | |
PostDatabaseItem | Usage: Comments: Returns: |
PatchDatabaseItem | Usage: Comments: Returns: |
GetColumnNames | Usage: Comments:
Returns: |
GetColumnValues | Usage: Comments: Returns: |
...
GetMVGroupNames | Usage: Comments: Returns: |
Params
The proper use of the generic arguments are defined in the definition of each service above.