Typical way to design and expose HTTP API today is a so called CRUD approach: come up with URL templates for resources, map create-read-update-delete operations to HTTP verbs and serialize domain model as JSON. This approach is nice and easy, but has its limitations.
During this presentation we'll create an application enhancing its primitive CRUD API all the way to modern, business-centric hypermedia style API using a set of tools from Spring, namely Spring Boot, Spring Data REST, Spring HATEOAS and Spring REST Docs!
12. 12
if (status == Status.NEW) {
publishedAt = LocalDateTime.now();
status = Status.PUBLISHED;
} …
CRUD is NOT enough
if (status == Status.NEW) {
publishedAt = LocalDateTime.now();
status = Status.PUBLISHED;
} …
13. 13
API Changes
Method URL Task
POST /ads/{id}/publishing Publish ad
POST /ads/{id}/expiration Expire ad
GET /ads/search/published
Get published
ads
17. 17
URI Binding & Construction
Task Method URL
Update ad PATCH /ads/{id}
Delete ad DELETE /ads/{id}
Publish ad POST
/ads/{id}/
publishing
Expire ad POST
/ads/{id}/
expiration
18. 18
"Figuring" Out the Flow
Task Method URL
Update ad
(only if NEW) PATCH /ads/{id}
Delete ad
(only if NEW) DELETE /ads/{id}
Publish ad
(only if NEW) POST
/ads/{id}/
publishing
Expire ad
(only if
PUBLISHED)
POST
/ads/{id}/
expiration
44. 44
Outcomes - API
1. Use links for state transitions
2. Separate integration domain
from the core domain
3. Expose only the necessary parts
4. Leverage caching
5. Combine testing with
documentation
6. Do NOT document URLs!
45. 45
Outcomes -
1. Spring Data REST - simple, CRUD-
y and HATEOAS-y; extensible
PRO TIP: won't solve everything
2. Spring MVC - always there to help
3. Link stuff with Spring HATEOAS
4. Spring Security to the rescue
when you need to protect API
5. Document with Spring REST Docs