Abstract
As is the case with recipes, you could end up with an unpalatable meal using the same ingredients as for a truly tasty one. It all depends on the chef. The same is true with REST. There is a huge misconception that by using HTTP, sending back and forth XML/JSON documents, and using URLs to mark endpoints of an API is what counts toward being RESTful (the major three constituents associated with REST in marketing campaigns). Many development tools are built around this fallacy. REST is an instance of a profound paradigm shift pertaining to network-based architectures.
This is a preview of subscription content, log in via an institution to check access.
Access this chapter
Tax calculation will be finalised at checkout
Purchases are for personal use only
Notes
- 1.
Embedded systems can be built using the same REST principles without using HTTP. There is a standard called Constrained Application Protocol (CoAP) defined in RFC 7252 (see http://coap.technology and [1]) for devices with low capacity. CoAP delivers a non-HTTP REST model for such small devices.
- 2.
This might occur in RESTful services, too. For example, with security (based on obtaining a token), making a secure call without having the right token produces an exception. Web sites and browsers sometimes exchange shared state with cookies.
- 3.
With HTTP 2.0, even REST services will be able to allow efficient, fine-grained communication patterns. It is a binary protocol, uses header compression (only differences are passed along), and implements an efficient pipelining mechanism. HTTP 2.0 has the notion of a stream, which is a bidirectional virtual channel in a connection. Streams carry frames (a unit of data), and multiple frames constitute a logical request and response message. Frames can be interleaved in a connection. HTTP 2.0 doesn’t have the head-of-line blocking problem.
- 4.
It is possible to use persistent URLs (PURLs), which is another indirection mechanism for Web resources (for more information, visit https://purl.org ). This might give protection against domain name changes. Another more advanced possibility is to publish an OWL (see https://www.w3.org/OWL/ ) document with the following content (it is presented here in N-Triples format): @prefix owl: < http://www.w3.org/2002/07/owl #> .<old URL> owl:sameAs <new URL>
- 5.
Don’t mix the meaning of a resource here with our REST notion of a resource (a fine proof that most words in software engineering are pretty overloaded). The resources in this context are low-level system resources, like files, sockets, devices, and so on. Most often a process (as an executable code) cannot be migrated without migrating all referenced resources. It is easy to copy over a static file, but not that easy to transfer the state of the memory.
- 6.
When you return a media type in a response, then the response must fully follow that type. You cannot mix multiple types and just signal one of them. This is the reason it is a better strategy to choose a flexible, well-established hypermedia media type as a base (like JSON API), and customize it using a profile (e.g., by leveraging JSON-LD as presented in Chapter 7).
Author information
Authors and Affiliations
Rights and permissions
Copyright information
© 2016 Ervin Varga
About this chapter
Cite this chapter
Varga, E. (2016). Identifying Resources. In: Creating Maintainable APIs. Apress, Berkeley, CA. https://doi.org/10.1007/978-1-4842-2196-9_5
Download citation
DOI: https://doi.org/10.1007/978-1-4842-2196-9_5
Published:
Publisher Name: Apress, Berkeley, CA
Print ISBN: 978-1-4842-2195-2
Online ISBN: 978-1-4842-2196-9
eBook Packages: Professional and Applied ComputingProfessional and Applied Computing (R0)Apress Access Books