Early Review of draft-ietf-jmap-rest-00
review-ietf-jmap-rest-00-httpdir-early-nottingham-2024-02-21-00
| Request | Review of | draft-ietf-jmap-rest |
|---|---|---|
| Requested revision | No specific revision (document currently at 00) | |
| Type | Early Review | |
| Team | HTTP Directorate (httpdir) | |
| Deadline | 2024-03-15 | |
| Requested | 2024-02-19 | |
| Requested by | Mark Nottingham | |
| Authors | Joris Baum , Hans-Jörg Happel | |
| I-D last updated | 2024-08-22 (Latest revision 2024-02-19) | |
| Completed reviews |
Httpdir Early review of -00
by Mark Nottingham
|
|
| Assignment | Reviewer | Mark Nottingham |
| State | Completed | |
| Request | Early review on draft-ietf-jmap-rest by HTTP Directorate Assigned | |
| Reviewed revision | 00 | |
| Result | On the right track | |
| Completed | 2024-02-21 |
review-ietf-jmap-rest-00-httpdir-early-nottingham-2024-02-21-00
This specification defines a very small mechanism to expose JMAP via HTTP (although JMAP uses HTTP already, it does so in a highly specialised way that is not accessible to most HTTP clients). As a general comment, I wonder whether it's helpful to have "REST" in the title, since this is clearly a minimal API that happens to be exposed over HTTP; it has more to do with RPC than REST. Perhaps "JMAP HTTP Resource", "JMAP HTTP Interface" or similar? Two specific issues to consider: * Section 1.3 seems to implicitly reinvent RFC 6570. Have you considered using that syntax instead? * Section 2 always uses POST. Is it possible to map some calls to GET to obtain benefits such as caching, idempotence, retry ability, etc.?