DZone
Integration Zone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
  • Refcardz
  • Trend Reports
  • Webinars
  • Zones
  • |
    • Agile
    • AI
    • Big Data
    • Cloud
    • Database
    • DevOps
    • Integration
    • IoT
    • Java
    • Microservices
    • Open Source
    • Performance
    • Security
    • Web Dev
DZone > Integration Zone > Please, Don’t Call Them RESTful

Please, Don’t Call Them RESTful

A lot of people tend to use the word RESTful incorrectly. Read on to get one dev's take on why REST is so misunderstood.

Andrea Chiarelli user avatar by
Andrea Chiarelli
·
Feb. 28, 18 · Integration Zone · Opinion
Like (42)
Save
Tweet
15.81K Views

Join the DZone community and get the full member experience.

Join For Free

At the beginning of 2000, Douglas Crockford claimed that JavaScript was the World’s most misunderstood programming language. The reason for this misunderstanding was mainly due to bad naming, design errors, non-strict standard, etc. So, the misunderstanding was almost natural.

Last year I tweeted something similar about the REST architectural paradigm.

Image title

In fact, most people believe that to build a RESTful API you can simply create an API based on URLs and HTTP verbs. This is absolutely false.

This misunderstanding is going around for too long. But unlike JavaScript, the REST guidelines are clear enough. The name itself emphasizes the State Transfer, but this concept is the most ignored by the so-called RESTful API designers.

If you ask ten developers if their APIs support HATEOAS, at least nine will look at you with wide eyes saying: what f***ing are you talking about?

How to insult a developer

Yet the name speaks for itself. REST’s name says nothing about the protocols to be used and the way to identify a resource. It just speaks about REpresentational State Transfer. And state transfer management is a mandatory requirement for an API to be called RESTful, as Roy Fielding has stressed.

A true RESTful API is an API that provides the client with a new state and ways to switch to subsequent states. It provides a representation of a resource (not necessarily in JSON) and enriched links (hypermedia) to other related resources that may move the application to another state, as in the following example:

{
  "id": 463219,
  "firstName": "John",
  "lastName": "Smith",
  "company": "Acme Inc.",
  "salary": 72500,
  "links": [
    {
      "href": "https://api.myapp.com/employees/employee/463219",
      "rel": "self"
    },
    {
      "href": "https://api.myapp.com/companies/company/375",
      "rel": "company"
    },
    {
      "href": "https://api.myapp.com/payments/employee/463219",
      "rel": "payments"
    }
    ]
}

Here, the resource describes itself and provides information about related resources.

To be picky, it does not matter whether you use HTTP or another protocol. The key thing about the REST approach is that the server addresses the client state transitions. The state of the client is almost totally driven by the server and, for this reason, discussions on API versioning make little sense, too. All that a client should know about a RESTful interface should be the entry point. The rest should come from the interpretation of server responses. This is an interesting scenario rarely implemented.

APIs that simply map CRUD actions to HTTP verbs have nothing to do with Application State Transfer. You can call them Web APIs or HTTP APIs, but please don’t call them RESTful.

REST Web Protocols

Published at DZone with permission of Andrea Chiarelli. See the original article here.

Opinions expressed by DZone contributors are their own.

Popular on DZone

  • Waterfall Vs. Agile Methodologies: Which Is Best For Project Management?
  • How to Utilize Python Machine Learning Models
  • 4 Different Ways to Work With Nebula Graph in Apache Spark
  • How to Use Geofences for Precise Audience Messaging

Comments

Integration Partner Resources

X

ABOUT US

  • About DZone
  • Send feedback
  • Careers
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • MVB Program
  • Become a Contributor
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 600 Park Offices Drive
  • Suite 300
  • Durham, NC 27709
  • support@dzone.com
  • +1 (919) 678-0300

Let's be friends:

DZone.com is powered by 

AnswerHub logo