Re: [Jmap] Httpdir early review of draft-ietf-jmap-rest-00

Hi Joris,

My pleasure; it's nice to hear it was helpful.

Cheers!


> On 26 Feb 2024, at 18:43, Joris Baum <joris@audriga.com> wrote:
> 
> Thanks for the reviews!
> I am a bit unhappy about the state of the document myself. Your comments definitely helped and gave me some ideas on how to approach this. I will try to come up with something soon to address this.
> Regards,
> Joris
> On 26.02.24 02:35, Neil Jenkins wrote:
>> On Thu, 22 Feb 2024, at 16:01, Mark Nottingham via Datatracker wrote:
>>> * Section 2 always uses POST. Is it possible to map some calls to GET to obtain
>>> benefits such as caching, idempotence, retry ability, etc.?
>> 
>> I agree. I think for this mapping to be useful, it should aim to work as this style of API normally does, rather than aim to have the full capabilities of JMAP. So just map the CRUD operations, with each request operating on a single object rather than any kind of batching. Don't worry about the state strings. You'd probably still only need a single templated URL like:
>> 
>> apiRestUrl: "/api/{accountId}/{typeName}
>> 
>> 
>> Then you would map everything onto this. I would expect fetching a record to look something like:
>> GET /api/account1/Calendar/123-12345?properties=["name", "color"]
>> 
>> 
>> Returning:
>> {
>> "id": "123-12345",
>> "name": "Personal",
>> "color": "#ff0000"
>> }
>> 
>> or a 404  if not found.
>> 
>> Creates would be a POST to the type collection, updates would be a PATCH to the specific resource for an object, and destroys would be a DELETE to the resource.
>> 
>> Querying is the more interesting one, and a bit trickier to specify. I would expect something like:
>> 
>> GET /api/account1/Email?filter={"inMailbox":"inbox-id"}&position=10&limit=10&properties=["to","cc","receviedAt"]
>> 
>> to do an Email/query with the given filter/position/limit, then an Email/get for each of the results, with the properties passed through to that. Probably a JSON array of objects would be the response. You could again omit delta changes, state strings, returning the overall total, anchor-based querying etc. — just keep it simple.
>> 
>> Cheers,
>> Neil.
> -- 
> Joris Baum
> Tel: +49 721 170293 16
> Fax: +49 721 170293 179
> 
> http://www.audriga.com | http://www.twitter.com/audriga
> 
> --------------------------------------------------------------------------
> audriga GmbH | Alter Schlachthof 57 | 76137 Karlsruhe
> Sitz der Gesellschaft: Karlsruhe - Amtsgericht Mannheim - HRB 713034
> Geschäftsführer: Dr. Frank Dengler, Dr. Hans-Jörg Happel
> --------------------------------------------------------------------------

--
Mark Nottingham   https://www.mnot.net/

Received on Monday, 26 February 2024 10:39:00 UTC