Publication: Survey of Semantic Description of REST APIs
cris.customurl | 16546 | |
cris.virtual.department | Data Engineering | |
cris.virtual.department | #PLACEHOLDER_PARENT_METADATA_VALUE# | |
cris.virtual.department | #PLACEHOLDER_PARENT_METADATA_VALUE# | |
cris.virtual.department | #PLACEHOLDER_PARENT_METADATA_VALUE# | |
cris.virtual.department | #PLACEHOLDER_PARENT_METADATA_VALUE# | |
cris.virtual.department | #PLACEHOLDER_PARENT_METADATA_VALUE# | |
cris.virtual.department | #PLACEHOLDER_PARENT_METADATA_VALUE# | |
cris.virtual.departmentbrowse | Data Engineering | |
cris.virtual.departmentbrowse | Data Engineering | |
cris.virtual.departmentbrowse | Data Engineering | |
cris.virtualsource.department | #PLACEHOLDER_PARENT_METADATA_VALUE# | |
cris.virtualsource.department | 3a2553bc-4d23-4bae-a22f-5d92c868792c | |
cris.virtualsource.department | #PLACEHOLDER_PARENT_METADATA_VALUE# | |
cris.virtualsource.department | #PLACEHOLDER_PARENT_METADATA_VALUE# | |
cris.virtualsource.department | #PLACEHOLDER_PARENT_METADATA_VALUE# | |
cris.virtualsource.department | #PLACEHOLDER_PARENT_METADATA_VALUE# | |
cris.virtualsource.department | #PLACEHOLDER_PARENT_METADATA_VALUE# | |
dc.contributor.author | Verborgh, Ruben | |
dc.contributor.author | Harth, Andreas | |
dc.contributor.author | Maleshkova, Maria | |
dc.contributor.author | Stadtmüller, Steffen | |
dc.contributor.author | Steiner, Thomas | |
dc.contributor.author | Taheriyan, Mohsen | |
dc.contributor.author | Van de Walle, Rik | |
dc.date.issued | 2013-01-01 | |
dc.description.abstract | The REST architectural style assumes that client and server form a contract with content negotiation, not only on the data format but implicitly also on the semantics of the communicated data, i.e., an agreement on how the data have to be interpreted [247]. In different application scenarios such an agreement requires vendor-specific content types for the individual services to convey the meaning of the communicated data. The idea behind vendor-specific content types is that service providers can reuse content types and service consumers can make use of specific processors for the individual content types. In practice however, we see that many RESTful APIs on the Web simply make use of standard non-specific content types, e.g., text/xml or application/json [150]. Since the agreement on the semantics is only implicit, programmers developing client applications have to manually gain a deep understanding of several APIs from multiple providers. © Springer Science+Business Media New York 2014. All rights are reserved. | |
dc.description.version | VoR | |
dc.identifier.citation | Verborgh, R. et al. (2014). Survey of Semantic Description of REST APIs. In: Pautasso, C., Wilde, E., Alarcon, R. (eds) REST: Advanced Research Topics and Practical Applications. Springer, New York, NY. https://doi.org/10.1007/978-1-4614-9299-3_5 | |
dc.identifier.doi | 10.1007/978-1-4614-9299-3_5 | |
dc.identifier.isbn | 9781461492993 | |
dc.identifier.uri | https://openhsu.ub.hsu-hh.de/handle/10.24405/16546 | |
dc.language.iso | en | |
dc.publisher | Springer Science + Business Media | |
dc.relation.orgunit | Karlsruhe Institute of Technology | |
dc.rights.accessRights | metadata only access | |
dc.subject | Application programming interfaces (API) | |
dc.subject | Semantics | |
dc.subject | Application scenario | |
dc.subject | Architectural style | |
dc.subject | Client application | |
dc.subject | Individual service | |
dc.subject | OR application | |
dc.subject | Reuse | |
dc.subject | Semantic description | |
dc.subject | Service consumer | |
dc.subject | Service provider | |
dc.subject | Specific processor | |
dc.title | Survey of Semantic Description of REST APIs | |
dc.type | Sammelbandbeitrag oder Buchkapitel | |
dcterms.bibliographicCitation.booktitle | REST: Advanced Research Topics and Practical Applications | |
dcterms.bibliographicCitation.originalpublisherplace | New York | |
dspace.entity.type | Publication | |
hsu.peerReviewed | ✅ | |
hsu.uniBibliography | Nein | |
oaire.citation.endPage | 89 | |
oaire.citation.startPage | 69 |