Tag Info

Hot answers tagged

30

Call it an HTTP API. It conforms to HTTP standards, and doesn't have anything else layered on top (e.g. SOAP). The HTTP standards define resources, verbs, headers, content negotiation, etc. REST (REpresentational State Transfer) is an architecture with requirements that happen to be amenable to existing HTTP standards, but HTTP works on all its own. ...


17

Richardson Maturity Models goes like this POST everywhere. A single endpoint. (SOAP) POST everywhere. Multiple endpoints. (resources) HTTP VERBS. Multiple endpoints. Like 2 and returns links to resources. (RESTful) So according to the model I would call it a webservice conforming to richardson level 2 or something along those lines. ...


5

Using function names to differentiate among n true/false behaviors will result in 2n functions. This is easy to manage when n is a small value like 2 or 3, but it gets out of hand very quickly with anything greater. The POSIX open(2) call has nine true/false variants, and if that were written as one function per combination, you'd be staring down 512 ...


4

Hypermedia never really got popular with REST-like APIs - to the point that when an API actually implements hypermedia navigation, the term RESTful simply isn't enough to distinguish it from any other "RESTful" web APIs. REST has become an catch-all term or any resource-based web APIs and new names like Hypermedia API have been coined to focus on ...


4

I think you are starting from the wrong end. API design is about what the client/requester requires not about how you represent the data internally. If the client need the category name then just provide it along with the id (if its useful to the client). As a Post belongs to only one category there is no reason to have anything other than a flat structure. ...


3

Structurally, I would reconsider the notion that a post belongs to a category. That's a strange way to model the relationship, especially considering a post very well may form a relationship with multiple categories. So in my mind a post has multiple categories. As @James Anderson initiated, you shouldn't think about your API as a result of your persistence ...


3

The amount of variables (and hence, the magnitude of the combinatorial explosion) can be reduced with a more general and modular API. For example, instead of making Find support substrings, create a separate function that takes a substring out of a string. Instead of returning either the start of the end of the match, always return the start and make it easy ...


3

So my question is why people use GET in an API if is less secure? People often think using POST requests are a solution to CSRF but POST requests are still vulnerable and if CSRF prevention is your goal then you should implement a CSRF token. However, CSRF is not usually considered a threat to an API because the fundamental premise of a CSRF attack ...


2

It is a CRUD interface (Create, Read, Update, Delete) over HTTP. I can't think of any authorities to back it up this assertion, so I hope you get more and better answers.


2

I would follow the YAGNI principle and carefully think through what the client needs on his/her side. Including things that you think the client is going to need is a symptom of a core problem - that being lack of research and/or knowledge what the client actually needs.


1

Normally, no. The callback is part of the API exposed by layer B. The API of Layer B defines the form (prototype) of the callback, the API of Layer B defines the functions to register and unregister the callback, and Layer B defines the conditions under which the callback will be invoked. Furthermore, since the callback gets registered, it will work even ...


1

You can call it a Web API. It's a very broad term but it can avoid nitpicking about meaning of other API type definitions. The term is less technical and precise compared to alternatives like HTTP API, but that might be an advantage when talking to non-technical people. This term is also used by Leonard Richardson (who defined the Richardson Maturity Model ...


1

You can call it whatever you like, people tend to (almost religiously) latch onto any part of the REST 'spec' that you're not following and use that as a point of protest which is highly detrimental to the development. But that said, the simple fact is that there are (nearly) zero services exist that implement true REST for their API serves. In our team we ...


1

Is your library a weather api that uses existing web services to get data? In that case you should probably hide the details of the actual ws, and define your own set of attributes for weather data. That way you encapsulate the external dependency from the users of the api. You may also want to watch how you get data from the xml. Try to only bind your ...


1

If the purpose of your API is just to provide data (which is true in my opinion), then do not return redundant or formatted values. In your example, returning single date/time is enough. This makes your response more concise and less ambitious. Making assumptions about consumer GUI and interpretation of provided data is usually wrong approach, avoid.


1

While I agree with James, sometimes for whatever reasons you may want to have objects, so as to have a better representation of the actual data. In those cases, there are two considerations: Having just CategoryId, if you laways or almost always need the name, will require another request; Having both options is pretty useless since Post.CategoryId is not ...


1

A resource is a resource. The resource doesn't change simply because the permissions change. What you can do with the resource or what you can know about the resource might change, but the mapping of the resource doesn't change. If it does it becomes a different resource type. So in your description, it's conceivable that various properties would exist at ...


1

For the edit/admin interface, a SPA is fine. For viewing the content, though I wouldn't recommend a SPA. Generally, you want to generate static pages from the content a user enters. This is faster/cheaper at runtime (serving static HTML is far easier than reading content from a DB and then rendering a page), and better for SEO. It's the approach used by ...



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