Repository navigation
Ore V2 API design #449
Description
This is subject to negotiation as to the order of implementation, and what other things are considered high priority. All v2 endpoints should be in swagger or openapi. other sponge projects using these apis will rely on auto generated clients based on these api definition files.
All endpoints except potentially download should require tokens
- see JWT Implenetation #441 and Json Web Token - JWT SpongeAuth#155
- All endpoints should be grouped via routes, and in code as if ore's backend was separate microservices to enable us to split out ore into microservices in the future to enable us to scale ore better.
- Api keys need further control as to scoping API rename, and add scoping controls, and owner/organization level keys #439
Priority endpoints to implement equivalents of in v2 api
Activity
phit commentedon Jun 17, 2019
Wanted to write down my thoughts in the API right now:
Consider making sessions optional for public use, they add no purpose for us. People can simply create new sessions on a new IP at any point in time to bypass any form of rate limiting you could impose on a session. I would suggest simply rate-limiting public users by IP address and not session key. If people do wanna use sessions on public use, fine but I don't see an argument for enforcing it.
Currently after receiving your session the HTTP standard Authorization header is being used, there's a few issues with this approach how it is right now:
Authorization: ApiSession key>Authorization: OreAuth session=keyOreAuth and session are placeholders we could change that to whatever we desire really, we just need to stick to the spec of the standard header.
What I would suggest instead is just creating our own header, this will avoid any potential conflicts. I would suggest:
OreSession: keyI also read the linked issues for using JWT, but I agree this is currently probably not needed.