Tag Info

Hot answers tagged

6

Don't invent status codes You are not expected to invent your own response codes, since the point of the API is to use a standard interface any developer can understand. The fact that you maintain both the API and its client is irrelevant: since everyone can trace the calls to the API, everyone can implement a different client. The point of using standard ...


6

I am not a lawyer and you aren't even saying which jurisdiction applies to you, so no legal advise from me. But from a purely practical standpoint, building a product based on an undocumented API is a very bad idea. You have no way to tell if the API will still be there tomorrow. The one who made it can destroy your whole work with a single change to their ...


3

No one said you can't make a URI for /api/foos/?page=1. A container is not the same as the things it contains; a list of foos is a different resource from the individual foos.


2

An API stands for "Application Programming Interface". It means any interface between the system, library or device and your development. So, no. An API is any programmatic interface, whether its a library with exposed C functions or a webserver with exposed REST verbs or anything in between.


2

I don't think they necessarily relate at all. DDD is about designing software from a business domain perspective, utilizing an ubiquitous language that you and your customer both understand. Many software developers mistake it for a programming technique, but it's more of a way to organize potential software structures (i.e. classes) around business domain ...


1

There are a few things that make this API not very RESTful: REST API URLs identify resources, not actions. First, actions should not be part of the URL path. The actions are the different HTTP methods. Instead of doing something like GET /api/person/findByEmail/ssmith@acmeco.com, you should remove findByEmail and use query parameters to convey that you're ...


1

I think option 2 is your best bet. While the public and admin sites are related and use the same DB most likely, admin use cases and work flows typically have little overlap with the use cases and workflows in the public site. So the admin site will likely have its own distinct set of business logic. You can certainly move code which is common into ...


1

Given the way the question is phrased, there obviously cannot be the correct answer, but you are asking for pros and cons. Here I argue solely for concrete code. My first argument against schema comes along as a question: why not WADL? You want it more lightweight and in JSON! Are you sure you know where to cut the weight on WADL without later learning that ...



Only top voted, non community-wiki answers of a minimum length are eligible