REST in peace?

Maurizio @sithmel

is REST dead?

Should we only use GraphQL now?

I've seen things you people wouldn't believe. Attack ships on fire off the shoulder of Orion. I watched C-beams glitter in the dark near the Tannhäuser Gate. All those moments will be lost in time, like tears in rain. Time to die.

I've seen things you people wouldn't believe. XML-RPC, api automatically built out of a WSDL, SOAP XML payloads. All those moments will be lost in time, like tears in rain. Time to use REST.

REST is an architectural style rather than a technology

Simple concepts

• Resource

• State change

• Representation

Simple concepts

• URL

• HTTP verbs

• Content type

URL

Unified resource locator

Where the resource is

Resource is the unit of data

Validation

Authentication & authorisation

Caching

REST resource should not necessarily mirror the db structure

Do not design an API in advance

If you need multiple request to do what you need, you are doing it wrong

Query parameters are part of the URL

https://www.tes.com/api/data/1?onlyIds=true

Use them for filtering data for example. They will be treated as different resources

Filter data easily with REST

http://resource-review/api?_includes=users[:10]name 

https://www.npmjs.com/package/express-middleware-filter-data

Verbs

What to do with a resource

Safety

Can be cached!

No consequences on the data stored

Idempotence

Safe to retry if fails

It doesn't matter if I call it multiple times

Representation

• JSON

• HTML

• XML

• Transit

• Literally everything

• MessagePack

Advanced features

Stream parsing

Conditional GET

Fine tuned caching

range request

Content negotiation

Really just all HTTP features

Multiple standard response code

Break these principles at your peril

Different resources on same URL

Unsafe GET

*Wrong verb

GRAPHQL Myths

GRAPHQL Facts

Save a lot of time if you want to see your data in multiple shapes/combinations (Just like FB)

It is convenient with Apollo/React

Others?