Node API V2 #28
Node API V2 #28
Conversation
quentinlesceller
added
core
|
Ready for review. |
|
How do you return errors in the new API? Are they typed or do you only rely on HTTP statuses? Can you add an example? |
|
@Kargakis I'll add a few examples of errors you can get! |
|
@Kargakis added a few examples. But basically it's like the v2/v3 grin-wallet API. |
There was a problem hiding this comment.
@quentinlesceller really nice job on this - I'd gladly shepherd this RFC through the process of getting merged, if okay. Just gave some minor feedback inline.
More generally, as this will be a reference document if merged, it's good to write the RFC in present tense like it has already been approved and merged. And avoid having language like "if accepted" or "proposed" in it, as it will only be live if accepted already, if that makes sense.
See a similar discussion on RFC0005 here.
There was a problem hiding this comment.
Hi @quentinlesceller I took another detailed pass on the document, see comments of minor tweaks.
The actual API documentation looks really good to me - reads clear. I only had suggestions to make the RFC be more "future proof" so that it remains up to date and accurate even after it's been merged, and some minor tweaks here and there.
text/0000-node-api-v2.md
Outdated
|
|
||
| ## Authentication | ||
|
|
||
| Like the v1 API, the v2 API uses basic auth with the same secret. This token is usually in `grin/main/.api_secret`. |
There was a problem hiding this comment.
Perhaps this model is too simple, we clearly have more than one API here, at least 2 - data consumer and node management (perhaps also data producer - push_tx), which may require different tokens or more granular auth model.
There was a problem hiding this comment.
Clearly we could separate them in 2 or 3 difference endpoints. Do we want to add such complexity though. For such use case someone can just build a middleware on top of it to filter the requests?
There was a problem hiding this comment.
Logically we have 2 APIs here, let's call them Blockchain API and Node API. The former is not node-specific (at least eventually), the later is. There are 2 different use cases and sets of clients. Security-wise exposing node api to internet is very risky. It's not that easy to restrict access to different JSON-RPC calls as for REST API (simple URL filtering is enough).
Token per endpoint model doesn't seem too hard to me, 1-2 lines of code to lookup a config key eg api_token_{endpoint_name}
There was a problem hiding this comment.
I see what you mean. However I'm still not sure it's worth the additional complexity here. It's also possible to do filtering with JSON RPC method. Not against but not convinced :)
There was a problem hiding this comment.
I agree with this concern, it might be worthwhile to split them. A wallet only needs very few of these endpoints to fully function, so anyone exposing their node publically would prefer to only have those few methods available on the outside (or without api secret token).
|
In accordance with our RFC process, as of today this can be considered in Final Comment Period with a disposition to merge. |
|
@hashmap @jaspervdm do you mind reviewing the recent Owner / Foreign API changes, before I merge the RFC? |
|
🎉 Wohooo! This RFC has now been merged! 🤸♀️ |
Rendered link to RFC document.