APIs over HTTP
REpresentational State Transfer
| REST | SOAP |
|---|---|
| Architecture | Protocol |
| Unique identification of resources | No identification of resources |
| Relies on transport | Transport agnostic |
| By discovery | By contract |
| Light & simple | Heavy & complex |
| For collections | For services |
Just a tunnel for remote invocation mechanism
POST /appointmentService HTTP/1.1
{ date: "2010-01-24", doctor: "martin" }
HTTP/1.1 200 OK
{ openSlotList: [
{ start: 1400, end: 1450, doctor: "martin" },
{ start: 1600, end: 1650, doctor: "martin" }
]}
POST /appointmentService HTTP/1.1
{
slot: { start: 1400, end: 1450, doctor: "martin" },
patient: { id: "brown" }
}
HTTP/1.1 200 OK
{
slot: { start: 1400, end: 1450, doctor: "martin" },
patient: { id: "brown" }
}
HTTP/1.1 200 OK
{
error: "Booking failure"
}
Start to talk to identifed resources
POST /doctors/martin HTTP/1.1
{ date: "2010-01-24" }
HTTP/1.1 200 OK
{ openSlotList: [
{ id: 1234, start: 1400, end: 1450, doctor: "martin" },
{ id: 5678 start: 1600, end: 1650, doctor: "martin" }
]}
POST /slots/1234 HTTP/1.1
{
patient: { id: "brown" }
}
HTTP/1.1 200 OK
{
slot: { start: 1400, end: 1450, doctor: "martin" },
patient: { id: "brown" }
}
Start to use HTTP verbs and status codes
GET /doctors/martin/slots?date=20100104&status=open HTTP/1.1
HTTP/1.1 200 OK
{ openSlotList: [
{ id: 1234, start: 1400, end: 1450, doctor: "martin" },
{ id: 5678 start: 1600, end: 1650, doctor: "martin" }
]}
POST /slots/1234 HTTP/1.1
{
patient: { id: "brown" }
}
HTTP/1.1 201 Created
Location: slots/1234/appointment
{
slot: { start: 1400, end: 1450, doctor: "martin" },
patient: { id: "brown" }
}
Hypermedia As The Engine Of Application State
GET /doctors/martin/slots?date=20100104&status=open HTTP/1.1
HTTP/1.1 200 OK
{ openSlotList: [
{ id: 1234, start: 1400, end: 1450, doctor: "martin",
links: [ {rel: "book", uri: "/slots/1234 } ] },
{ id: 5678 start: 1600, end: 1650, doctor: "martin" ,
links: [ {rel: "book", uri: "/slots/5678 } ] } ]}
POST /slots/1234 HTTP/1.1
{
patient: { id: "brown" }
}
HTTP/1.1 201 Created
Location: slots/1234/appointment
{ slot: { start: 1400, end: 1450, doctor: "martin" },
patient: { id: "brown" }, links: [
{ rel: "self", uri: "/slots/1234/appointment" } ] },
{ rel: "cancel", uri: "/slots/1234/appointment" } ] } }
| Operation | Verb | Example |
|---|---|---|
| Create | POST | curl -X POST -d '{patient: { id: "brown" }}' https://api.book-a-doctor.com/slots/1234 |
| Read | GET | curl -X GET https://api.book-a-doctor.com/doctors/martin/slots?date=20100104&status=open |
| Update | PUT | curl -X PUT -d '{name: "Martin", firstname: "John" } https://api.book-a-doctor.com/doctors/martin |
| Patch | PATCH | curl -X PATCH -d '{firstname: "Peter" } https://api.book-a-doctor.com/doctors/martin |
| Delete | DELETE | curl -X DELETE https://api.book-a-doctor.com/doctors/martin |
filter : filter to apply to elements to return
offset : index of first element to return
limit : maximal number of elements to return
sort : sorting of elements to return
This is just an example of a possible implementation. This is not standard.
Client's preferences are indicated in Accept header (format, language, encoding, etc ...)
Server answers as best as it can to client's expectations
Nobody understands REST : http://williamdurand.fr/2015/06/02/video-nobody-understands-rest
Webservices with Spring : http://spring.io/guides/tutorials/bookmarks/

Let's expose APIs !