I am having trouble naming rest endpoints for my otp service.
Here I have 4 endpoints, in brackets I have given inputs
SEND API (Mo. No.) - Generates OTP and send to mobile number, in response it gives TransactionId
RESEND API (TransId) - Resend same OTP to mobile Number with the transactionId
VERIFY API (OTP, TransId)- Verify if the OTP given for the transactionId, is correct to what is stored in cache
ISVERIFIED API (TransId) - Check whether particular transactionId is verified or not
Can anyone please tell me how should I make REST endpoints for these APIs, adhere-ring to REST principles of resources, etc.
I thought of
POST v1/sendOTP
POST v1/resendOTP
POST v1/verifyOTP
POST v1/isVerifiedTransaction
Obviously, this is not a good design of endpoints, I need some help
Better approach would be
POST v1/send-otp
POST v1/resend-otp
POST v1/verify-otp
POST v1/is-verified-transaction if you have to make the separate endpoint for each
else as these can be part of the same end-point only the payload can be different, you cna do something like
POST v1/otp?action=send
POST v1/otp?action=re-send
POST v1/otp?action=verify
POST v1/is-verified-transaction or v1/transaction?status=is-verified
Maybe you should have otp and transaction as resources and do something like this:
POST v1/otp/send
POST v1/transaction/{transId}/resend
GET v1/transaction/{transactionId}/verify?otp={otpId}
GET v1/transaction/{trandId}/isVerified
I am not sure how otp and transactions relate, so it might be a bit off, just throwing the idea of having them as resources
Related
GET /customers/{customer-id}
I am designing an API where the customer gets identified with the Authorization token passed in the request header. This means the above API doesn't require the customer-id in the URI.
Wondering what is recommended or the best options? These are some of the options which I can think of:
GET /customers/me
GET /customers/self
GET /customers/this
I have used 'me' a few times and the API consumers were fine with this. Thoughts?
As the title suggests, I am looking to have the client be able to check whether a username or email is already registered before the user submits the registration form. I had considered using an API endpoint that would return true or false for a given username, but this seems more RPC than RESTful. Is it bad practice to have such an endpoint if the rest of my API is RESTful? If so, what would a RESTful approach to this situation look like?
A key concept in REST is that anything that can be named can be a resource; this includes procedures. If you want to have an endpoint that accepts a username in the request body and returns true/false that's perfectly fine.
Alternatively, you can (or may already) treat a user as a resource. Take the GitHub API as an example: you can fetch a user by sending a GET request to https://api.github.com/users/{username}. If the user exists, and therefore the username is taken, you'll get back 200 OK. If the user does not exist you'll get 404 Not Found.
If you want to check if a username has been taken you can just issue a request for that username and then check the response. If you choose this approach HEAD is the more appropriate method. HEAD is essentially the same as GET except that the response body is empty. Since you don't need the body to determine if the user exists you can save a tiny bit of bandwidth with HEAD over GET.
You could do a POST /registrations and return a 400 with validation errors array and just have client side logic filter that array for invalid username. In other words, no reason you can't hit the endpoint multiple times. This should help decouple your UX from your API.
Sending email including new password to user is provided by rest api.
for example, after call "user/{email}", user will receive the email to get new password.
I think sending email is not kind of GET, PUT, POST, PUT.
How design url to more perfect restful api.
I think sending email is not kind of GET, PUT, POST, PUT.
That's true, but that's not what you are doing. You are sending a document to the server to advance a protocol, that has a side effect of sending an email. See Jim Webber
HTTP is an application protocol whose application domain is the transfer of documents over a network.
For the case of performing a password reset, you probably want clients to recognize that the operation is not safe. So you should prefer POST or PUT to GET.
On the web, where we are using HTML representations of resources, POST is the only option available to us, and it works just fine.
There is a lot of missing information here but have a look at Send Grid's API. I know this isn't a direct answer to your question, but I cannot leave comments.
What should be the standard approach for getting user information after login ?
POST request to validate user/password and retrieve information on response
POST request to validate user/password followed by GET request to retrieve information?
As far as I understand, GET should be the preferred one to retrieve data, but it seems burdensome to performe two requests; at the same time, it feels weird to get data back on POST response. Which should be preferred?
My 2 cents:) if you really want to follow REST Paradigm then you should use standard http method as GET. Although an overloaded POST might do the job however it’s not following the standard.
In SOAP world everything is POST and you can do a lot of funky stuff however in REST world there is a standard on what method used for what purpose ideally.
We have some IoT sensors that POST json payloads to an endpoint. They are configured with only a HTTPS URL to send to, no ability to setup authentication etc.
We need basic ability to see which sensor is sending data, and loosely prevent anyone from sending payloads. Full authentication will not be possible.
It was suggested we could put a token in the path and use it as a super basic API Key. I was wondering what the best format for the route should be...
/api/events/_ingest/api-key
/api/producer/api-key/events/_ingest
I was wondering what the best format for the route should be: /api/events/_ingest/api-key or /api/producer/api-key/events/_ingest
There's no best approach here, both are really bad. The API key does not belong to the URL. It should be sent in the standard Authorization HTTP header.
Once you mentioned in the comments that it will be something temporary, you could try a query parameter. It's still bad though. But you will be able to reuse this same route later, just moving the API key to a HTTP header, when your clients support it:
/api/events/_ingest?api-key=somecoolhashgoeshere