REST: Advanced Research Topics and Practical Applications

pp 69-89


Survey of Semantic Description of REST APIs

  • Ruben VerborghAffiliated withMultimedia Lab – Ghent University – iMinds Email author 
  • , Andreas HarthAffiliated withInstitute AIFB, Karlsruhe Institute of Technology (KIT)
  • , Maria MaleshkovaAffiliated withInstitute AIFB, Karlsruhe Institute of Technology (KIT)
  • , Steffen StadtmüllerAffiliated withInstitute AIFB, Karlsruhe Institute of Technology (KIT)
  • , Thomas SteinerAffiliated withDepartament de Llenguatges i Sistemes Informatics, Universitat Politècnica de Catalunya
  • , Mohsen TaheriyanAffiliated withInformation Science Institute, University of Southern California
  • , Rik Van de WalleAffiliated withMultimedia Lab – Ghent University – iMinds

* Final gross prices may vary according to local VAT.

Get Access


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.