I think you should avoid camel caps. The norm is to use lower case letters. I would also avoid underscores and use dashes instead So your URL should look like this (ignoring the design issues as you requested :-)) api.service.com/hello-world/user-id/x
You basically have two options: Use PATCH (but note that you have to define your own media type that specifies what will happen exactly) Use POST to a sub resource and return 303 See Other with the Location header pointing to the main resource. The intention of the 303 is to tell the client: “I … Read more
A previous answer only mentioned SSL in the context of data transfer and didn’t actually cover authentication. You’re really asking about securely authenticating REST API clients. Unless you’re using TLS client authentication, SSL alone is NOT a viable authentication mechanism for a REST API. SSL without client authc only authenticates the server, which is irrelevant … Read more
What doesn’t make sense: distributed transactions with REST services. REST services by definition are stateless, so they should not be participants in a transactional boundary that spans more than one service. Your user registration use case scenario makes sense, but the design with REST microservices to create User and Wallet data is not good. What … Read more
Try selecting send and download instead of send when you make the request. (the blue button) https://www.getpostman.com/docs/responses “For binary response types, you should select Send and download which will let you save the response to your hard disk. You can then view it using the appropriate viewer.”
The fundamental problem with RPC is coupling. RPC clients become tightly coupled to service implementation in several ways and it becomes very hard to change service implementation without breaking clients: Clients are required to know procedure names; Procedure parameters order, types and count matters. It’s not that easy to change procedure signatures(number of arguments, order … Read more
Returning the new object fits with the REST principle of “Uniform Interface – Manipulation of resources through representations.” The complete object is the representation of the new state of the object that was created. There is a really excellent reference for API design, here: Best Practices for Designing a Pragmatic RESTful API It includes an … Read more
General principles for good URI design: Don’t use query parameters to alter state Don’t use mixed-case paths if you can help it; lowercase is best Don’t use implementation-specific extensions in your URIs (.php, .py, .pl, etc.) Don’t fall into RPC with your URIs Do limit your URI space as much as possible Do keep path … Read more
Make a separate set of /memberships/ resources. REST is about making evolvable systems if nothing else. At this moment, you may only care that a given player is on a given team, but at some point in the future, you will want to annotate that relationship with more data: how long they’ve been on that … Read more
I agree with Fionn, but I’ll go one step further and say that to me the Page is not a resource, it’s a property of the request. That makes me chose option 1 query string only. It just feels right. I really like how the Twitter API is structured restfully. Not too simple, not too … Read more