Yes, as close to one-to-one as I could make it, really. I didn’t want AntTP to have much of an opinion on how those data types should be used, but rather a wrapper for the library APIs in REST.
There is a little creativity with the likes of stratchpads, as we basically have public/private stratchpads in reality, but not in name (in the autonomi API). From glimpsing a recent Maidsafe PR, it looked like they were moving towards formally exposing public scratchpads too at the API level, so I hope it is on the right track.
Additionally, I interpreted name in the same way for a number of endpoints for deriving the keys, which isn’t fully consistent with the libraries. From testing, the same logic applies for deriving the keys, but the examples in the docs illustrate the key generation differently.
Additionally, there are binary and multipart endpoints (where applicable), which take raw application/octet streams and multipart/form-data respectively. These complement the JSON REST endpoints, but provide support for alternative interfaces, e.g. binary POSTs don’t need to be base64 encoded and add no other body properties and multipart POSTS expect a HTML form submission, with base64 encoded parts. These can both be handy for browser integration, where JSON REST may not be ideal.
Yes, I think that would make a lot of sense. Having a sort of ‘core’ set which purely echo the library and then a complimentary set to add features, seems like a good mix.
I would request that we went with the naming convention for using versioning in the URL though, if possible, e.g. REST API Versioning: How to Version a REST API? with /v1/*, /v2/*, etc. It’s not a requirement, but it’s very common and should help folks understand what we’re doing.
I stuck a /api prefix on the versions, just to make it clear that it was a special URL with API calls in it (as opposed to regular files in the path). However, it would be feasibly to route either, if you felt strongly against that (or any of the above, tbh - we could both support both, etc).
Yes sounds good. If we want /anttp/vX instead of /api/vX etc, I could get behind that too. I don’t need/mean to claim /api/vX as the standard, really. I just wanted it not to mess/conflict with anything else and it seemed a decent place to start.
FWIW, the lack of opinionated API endpoints was to encourage more logic to appear in client side libraries (e.g. in typescript). I think there is a place for both approaches though, depending on the goals of the service hosting the endpoints.
Maybe, in time, we could plug modules in that support extended service features, such as more opinionated APIs, etc. Popular ones would certainly end up bubbling up to the top. It would also allow folks to adopt a licensing model they are happy with (by including/excluding modules to suit).
Yes, seems like a great idea and a good time to start pushing towards this.
Note that the v1 endpoints on AntTP are very much v1! 